mbuf changes
Julian Elischer
julian at freebsd.org
Sun Sep 26 06:45:02 UTC 2010
On 9/25/10 1:20 AM, Andre Oppermann wrote:
> On 25.09.2010 09:19, Julian Elischer wrote:
>> over the last few years there has been a bit of talk about some
>> changes people want to see in mbufs
>> for 9.x
>> extra fields, changes in the way things are done, etc.
>>
>> If you are one of these people, pipe up now..
>>
>> to get the ball rolling..
>>
>> * Add a field for the current FIB.. currently this is 4 bits stolen
>> from the flags.
>> what would be a good width: 8,12,16,24,32 bits?
>> this would allow setfib to use numbers greater than 16 (the current
>> max)
>
> 16 bits for 65535 FIB's should be sufficient. More than that seems
> really
> excessive.
>
>> * Preallocating some room for some number of tags before we start
>> allocating
>> (expensively) new ones.
>
> Within the mbuf? Or at external and attached mbuf allocation time?
> Tags
> are variable width and such not really suitable for pre-allocation.
yes possibly within.. thre could be for example a reaserver 20 byte
field and if it
doesn't fit in that we go to expensive tags.
I'm just waving my arms here.
>
>> * dynamically working out what the front padding size should be..
>> per session.. i.e.
>> when a packet is sent out and needs to be adjusted to add more
>> headers, the originating
>> socket should be notified, or maybe the route should have this
>> information...
>> so that future packets can start out with enough head room.
>> (this is not strictly to do with mbufs but might need some added
>> field to point to the structure
>> that needs to be
>> updated.
>
> We already have "max_linkhdr" that specifies how much space is left
> for prepends at the start of each packet. The link protocols set
> this and also IPSec adds itself in there if enabled. If you have
> other encapsulations you should make them add in there as well.
this doesn't take into account tunneling and encapsulation.
we could do a lot better than this.
especially on a per-route basis.
if the first mbuf in a session had a pointer to the relevent rtentry,
then as it is processed that could be updated..
just an idea.
More information about the freebsd-net
mailing list