julian at freebsd.org
Mon Sep 27 16:12:44 UTC 2010
On 9/27/10 6:09 AM, Andre Oppermann wrote:
> On 26.09.2010 08:32, Julian Elischer wrote:
>> 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
>>>> * Preallocating some room for some number of tags before we start
>>>> (expensively) new ones.
>>> Within the mbuf? Or at external and attached mbuf allocation time?
>>> 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.
> See my reply to Luigi for a detailed view on this.
>>>> * 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
>>>> 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
>>> 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.
> It should/could but the tunneling and encapsulation protocols have to
> add themself to it when active. IPSec does this.
yes bit the troubel is that every packet is then given a worst -case
reserved area at the front
>> 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..
> Please please please don't add a rtentry pointer to the mbuf. Besides
> that the routing table is a very poor place to do this. We don't have
> host routes anymore and the locking and refcounting is rather
yes but we do have a route cache
(and we probably should still have some form of host routes but that's a
different issue not to be argued here.)
> max_linkhdr should be sufficient (fix small fixes to some protocol mbuf
> allocators) even for excessive cases of encapsulation:
max-linkhdr is way too big for 99% of all packets.
> TCP over IPv4 over IPSec(AH+ESP) over UDP over IPv6 over PPPoE over
> Ethernet =
> 60 + 20 + (8+24) + 8 + 40 + 8 + 14 = 182 total, of which 102 are
> Maybe we need an API for the tunneling and encapsulation protocols to
> add their overhead to max_linkhdr.
More information about the freebsd-net