Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 24 Mar 2007 20:19:08 -0500
From:      Brooks Davis <brooks@freebsd.org>
To:        Hartmut Brandt <hartmut.brandt@dlr.de>
Cc:        freebsd-net@freebsd.org, freebsd-bugs@freebsd.org, Andre Oppermann <andre@freebsd.org>, Eugene Grosbein <eugen@kuzbass.ru>
Subject:   Re: kern/110720: [net] [patch] support for interface descriptions
Message-ID:  <20070325011908.GC7607@lor.one-eyed-alien.net>
In-Reply-To: <20070324182901.I59406@knop-beagle.kn.op.dlr.de>
References:  <200703231844.l2NIiCsa089542@freefall.freebsd.org> <20070324102948.Q58113@knop-beagle.kn.op.dlr.de> <4604FDD4.2080805@freebsd.org> <20070324123754.GA80483@svzserv.kemerovo.su> <20070324182901.I59406@knop-beagle.kn.op.dlr.de>

next in thread | previous in thread | raw e-mail | index | archive | help

--KDt/GgjP6HVcx58l
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Mar 24, 2007 at 06:37:59PM +0100, Hartmut Brandt wrote:
> On Sat, 24 Mar 2007, Eugene Grosbein wrote:
>=20
> 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=20
> EG>> >IF-MIB::ifDescr (255 byte + \0). Also I suppose that the field more=
=20
> EG>> >naturally fits into struct if_data (see net/if.h) given the comment=
 for=20
> EG>> >that struct:
> EG>> >
> EG>> >/*
> EG>> > * Structure describing information about an interface
> EG>> > * which may be of interest to management entities.
> EG>> > */
> EG>>=20
> EG>> The string array should most likely not be part of struct ifnet as t=
hat
> EG>> would bloat it quite a bit.  If it is in there it should be at the e=
nd
> 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 interface=
s,
> EG>think about large pptp or pppoe server or similar that never would
> EG>utilize arrays.
>=20
> That makes sense. If it is a pointer it should not live in struct ifdata=
=20
> which can be retrieved via sysctl().
>=20
> 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=
=20
> which returns a string. Could be IFDATA_DESCRIPTION (4). This would=20
> probably be more in line with the management nature of the data. Just a=
=20
> thought... Would be slightly easier for the SNMP daemon to use...

If must not live in struct ifdata as the size of struct ifdata is part
of the routing socket API. :(  There are two bytes avaible in struct
ifdata.

-- Brooks

--KDt/GgjP6HVcx58l
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (FreeBSD)

iD8DBQFGBc4MXY6L6fI4GtQRAjp0AKDL6bYit59V+7Fptg8/TtcijgyGHQCfSKqi
BnyLnBae+A2iduGFcBlwMvQ=
=E/BL
-----END PGP SIGNATURE-----

--KDt/GgjP6HVcx58l--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070325011908.GC7607>