Date: Sun, 9 Jan 2011 13:29:59 -1000 (HST) From: Jeff Roberson <jroberson@jroberson.net> To: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> Cc: freebsd-net@freebsd.org Subject: Re: vlan changes to support ipoib Message-ID: <alpine.BSF.2.00.1101091328190.1404@desktop> In-Reply-To: <20110109102339.K14966@maildrop.int.zabbadoz.net> References: <alpine.BSF.2.00.1101081838330.1404@desktop> <20110109102339.K14966@maildrop.int.zabbadoz.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 9 Jan 2011, Bjoern A. Zeeb wrote: > On Sat, 8 Jan 2011, Jeff Roberson wrote: > >> Hi Folks, >> >> I have made some changes to vlans and I was wondering if anyone would care >> to review or test. Especially current vlan users. The diff is here: >> >> http://people.freebsd.org/~jeff/vlan.diff >> >> I can't say that I like adding all of the function pointers but with vlan >> support available as a loadable module I have little choice. The new >> functions allow a driver to fetch the virtual interface associated with a >> tag, cache and fetch a cookie pointer in a virtual interface, and fetch the >> tag of a virtual interface. >> >> Additionally, the driver was changed to make no assumptions about address >> size unless the type is IFT_ETHER. This means for multicast entries we >> store a full sockaddr_dl rather than an ethernet address. It actually >> simplifies the code here. I also simplified the VLAN_ARRAY stuff by moving >> it into functions that match the hash names so there aren't ifdef's >> everywhere. I've tested both hash and array. >> >> I also changed the global mtx to an sx lock so the vlan_config event >> handlers can allocate memory. The way ipoib works requires a full new >> ipoib softc when a vlan is created. I didn't want to duplicate the vlan >> config logic so I store that softc using the cookie field and fetch it when >> necessary. As a result ipoib also doesn't need the weird vlan_input() >> recursion since the packets appear on the correct device as they are >> received. >> >> I am committing this to my infiniband tree immediately but I would like >> some review before I merge to current. > > May I ask you to split the diff up into logical junks for both review > and commit? Otherwise possible errors not caught with by review will > just be a lot harder to track down later. Most if not all of the chunks are interdependent or useless without each other. When I commit to current it will probably be a merge from my branch anyway. What would you like to see separated? > > Some of the stuff like "Initialize from parent" seems to be simple > enough to be possibly merged just upfront leaving the real beef. I notice that I don't have many comments. Perhaps if I documented better what I have done it would be sufficient? Thanks, Jeff > > /bz > > -- > Bjoern A. Zeeb You have to have visions! > <ks> Going to jail sucks -- <bz> All my daemons like it! > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1101091328190.1404>