Date: Wed, 09 Aug 2000 08:27:15 +1000 From: Peter Jeremy <peter.jeremy@alcatel.com.au> To: Blaz Zupan <blaz@amis.net>, hackers@FreeBSD.ORG Subject: Re: VLAN Support in FreeBSD Message-ID: <00Aug9.082728est.115210@border.alcanet.com.au> In-Reply-To: <Pine.BSF.4.21.0008081705540.60281-100000@titanic.medinet.si>; from blaz@amis.net on Tue, Aug 08, 2000 at 05:06:11PM %2B0200 References: <00Aug8.162756est.115205@border.alcanet.com.au> <Pine.BSF.4.21.0008081705540.60281-100000@titanic.medinet.si>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2000-Aug-08 17:06:11 +0200, Blaz Zupan <blaz@amis.net> wrote: >http://www.euitt.upm.es/~pjlobo/fbsdvlan.html Very useful. Upon further reflection last night, I decided that the problem was most likely related to the NIC's idea of what was the largest allowed frame - and the URL above includes fixes for the FXP and 3C905B. Currently, the vlan code (in if_vlan.c:vlan_config()) uses the parent device's if_data.ifi_hdrlen to decide whether the device can support 802.1q frames (ie whether or not to decrease the vlan MTU by 4 bytes). I'm not sure that this is the correct approach - it definitely strikes me as a hack (and isn't supported by any drivers). In any case, since FreeBSD can support a mixture of 802.1q and standard frames on the one NIC, the correct value for ifi_hdrlen is unclear. I believe a better approach to the problem would be to define a new interface flag bit (eg IFF_802_1Q or IFF_VLAN) which a NIC driver sets if it can correctly handle 802.1q frames (ie 1522 bytes). if_vlan.c:vlan_config() would then test this bit to see if it can use the parent devices MTU, or has to allow for the encapsulation overhead itself. The biggest problem with this approach is that there are no free bits in if_flags. I don't believe any of the existing bits can be reused (in particular, all 3 link bits are used by a number of ethernet drivers). I can't readily see any other free bits in struct ifnet (though there's 2 byte of padding in struct if_data). Another alternative would be for if_vlan.c:vlan_config() to use a callback to the parent device to check for 802.1q support. The driver could then configure itself to support 802.1q frames (if possible), update if_data.ifi_hdrlen as appropriate and return the MTU allowed for the vlan device. I believe this approach would be overkill (since it needs an additional callback in struct ifnet and an additional function in (eventually) most ethernet drivers - for little apparent benefit). Is there justification for increasing the size of if_flags? (Or splitting them between struct ifnet and struct if_data). Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?00Aug9.082728est.115210>