Date: Sat, 24 Mar 2007 18:37:59 +0100 (CET) From: Hartmut Brandt <hartmut.brandt@dlr.de> To: Eugene Grosbein <eugen@kuzbass.ru> Cc: freebsd-net@freebsd.org, freebsd-bugs@freebsd.org, Andre Oppermann <andre@freebsd.org> Subject: Re: kern/110720: [net] [patch] support for interface descriptions Message-ID: <20070324182901.I59406@knop-beagle.kn.op.dlr.de> In-Reply-To: <20070324123754.GA80483@svzserv.kemerovo.su> References: <200703231844.l2NIiCsa089542@freefall.freebsd.org> <20070324102948.Q58113@knop-beagle.kn.op.dlr.de> <4604FDD4.2080805@freebsd.org> <20070324123754.GA80483@svzserv.kemerovo.su>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 24 Mar 2007, Eugene Grosbein wrote: EG>On Sat, Mar 24, 2007 at 11:30:44AM +0100, Andre Oppermann wrote: EG> EG>> Harti Brandt wrote: EG>> >Nice feature, although it would be nice to align the maximum length with EG>> >IF-MIB::ifDescr (255 byte + \0). Also I suppose that the field more EG>> >naturally fits into struct if_data (see net/if.h) given the comment for EG>> >that struct: EG>> > EG>> >/* EG>> > * Structure describing information about an interface EG>> > * which may be of interest to management entities. EG>> > */ EG>> EG>> The string array should most likely not be part of struct ifnet as that EG>> would bloat it quite a bit. If it is in there it should be at the end EG>> of the struct to avoid cache line busting effects. EG> EG>Also vote for this. And is it possible to make it a pointer instead EG>of array? The bloat would be minimal for system with tons of interfaces, EG>think about large pptp or pppoe server or similar that never would EG>utilize arrays. That makes sense. If it is a pointer it should not live in struct ifdata which can be retrieved via sysctl(). As for access to this field perhaps it makes more sense to use the sysctl net.link.generic.ifdata subtree. We have already IFDATA_DRIVERNAME there which returns a string. Could be IFDATA_DESCRIPTION (4). This would probably be more in line with the management nature of the data. Just a thought... Would be slightly easier for the SNMP daemon to use... harti
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070324182901.I59406>