svn commit: r189230 - head/sys/net

[Robert Watson]

On Sun, 1 Mar 2009, Luigi Rizzo wrote:

> On Sun, Mar 01, 2009 at 12:42:54PM +0000, Robert Watson wrote:
>> Author: rwatson
>> Date: Sun Mar  1 12:42:54 2009
>> New Revision: 189230
>> URL: http://svn.freebsd.org/changeset/base/189230
>>
>> Log:
>>   Do a bit of struct ifnet cleanup in preparation for 8.0: group function
>>   pointers together, move padding to the bottom of the structure, and add
>>   two new integer spares due to attrition over time.  Remove unused spare
>>   "flags" field, we can use one of the spare ints if we need it later.
>>
>>   This change requires a rebuild of device driver modules that depend on
>>   the layout of ifnet for binary compatibility reasons.
>
> any chance to do similar things for other key kernel structures, such as 
> mbufs and struct bio ?
>
> As an example, "struct bio" would benefit from at least one extra intptr_t 
> field to be used for classification purposes (see some recent work we have 
> been doing on disk scheduling). This is a rather trivial and unintrusive 
> change.
>
> struct mbuf would benefit from a 'length' field, replacing the hardcoded 
> MLEN/MHLEN. This field would allow us to do several things, e.g.:

Jeff has a large work-in-progress on mbufs, and so I don't want to go near 
that until all that work has shaken out.  This includes support for 
variable-size mbufs and eliminating large amounts of cluster use (while 
retaining support for external storage, a we require that for zero-copy foo). 
If you haven't seen his posts about that work, you might want to give them a 
skim -- I think they were on arch@/net at .

I thought bio was less sensitive to change since it was centrally allocated 
these days, or is that not the case?  ifnet is decreasingly sensitive.

Robert N M Watson
Computer Laboratory
University of Cambridge

> - use part of the data area to store m_tags instead of having
>  to malloc() them separately;
> - support multiple (or perhaps even runtime-configurable) mbuf sizes
>  (and corresponding uma zones), so people could experiment with
>  larger MBUFS and perhaps figure out what is the performance impact
>  of using mbuf+clusters instead of individual mbufs for basically
>  every incoming packet.
>
> cheers
> luigi
>