From owner-cvs-all@FreeBSD.ORG Sun Sep 18 17:59:48 2005 Return-Path: X-Original-To: cvs-all@FreeBSD.org Delivered-To: cvs-all@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 87FCC16A41F; Sun, 18 Sep 2005 17:59:48 +0000 (GMT) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 13FD243D45; Sun, 18 Sep 2005 17:59:48 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.192] ([10.0.0.192]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j8IHxj6j073628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 18 Sep 2005 10:59:45 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <432DAABC.4040308@errno.com> Date: Sun, 18 Sep 2005 10:58:20 -0700 From: Sam Leffler Organization: Errno Consulting User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Damien Bergamini References: <200509171241.j8HCf5ov019561@repoman.freebsd.org> <432C4C6F.80906@errno.com> <00d501c5bbc0$1e8a9240$0300a8c0@COMETE> <432C8486.8060808@errno.com> <00f701c5bc2b$faa6faf0$0300a8c0@COMETE> In-Reply-To: <00f701c5bc2b$faa6faf0$0300a8c0@COMETE> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/iwi if_iwi.c if_iwireg.h if_iwivar.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Sep 2005 17:59:48 -0000 Damien Bergamini wrote: > | > No, you missed the point. This is not a table of ieee80211_node's, but > | > just a table of the neighbours mac addresses. Thus there is no problem > | > with reference counting, locking and such. > | > The iwi_find_txnode() function just looks for a mac address in the table > | > and returns its index (an entry is created if it was not already existing). > | > | Sorry, you're correct, these are mac addresses and not node references. > | But the suggestion still holds. You've got a separate piece of > | per-node information that logically belongs in a driver-private area of > | the node. Having it there would eliminate the table lookup; you just > | take the node pointer and deref to get the index. The intent of > | driver-private node storage is to eliminate add-on tables like this. > > Yeah, I already used something similar in ral for per-node rate adaptation. > But I thought it would be an overkill here for such a simple task. > Moreover, I must maintain exactly the same table in h/w, so keeping the h/w > table in sync with net80211 nodes would be a nightmare. Not sure about the nightmare of syncing state or things being overkill. Doing per-driver state is very simple and if you need one piece of data you''re likely going to need more. The main advantage I can see to doing what I suggested is you eliminate a fixed-size table in your driver. I don't think you do lookups often so replacing the linear search with the O(1) deref probably doesn't matter. > > | Note that when I MFC'd changes in this driver recently that I did not > | MFC any of your WME mods. My suggestion was that you not MFC _some_ of > | the changes; not things like fixing hidden ap handling. re is the final > | arbiter of what can be MFC'd. > > Looks like it's already too late for BETA5 anyway ... How are you testing your WME support? Sam