On Mon, Oct 23, 2000 at 11:08:54AM +0200, Lennert Buytenhek wrote:
> Does anyone have an idea whether mbufs (BSD) solve this problem in a
> neater way?
["this" = need to increase header space when pushing in new hard
headers, like 4 byte VLAN tag header. ]
"yes" -- but you have to pay for fragment overhead there anyway,
and I seem to recall that there are network interface cards which
will require coalescing the fragments into contiguous buffer for
DMA assisted sending. There are smarter hardware in the market
which support scatter-grather from such fragments, e.g. all modern
stuff. But the more you give them fragments, the more you give
unwanted overhead for them.
Also SysV STREAMS are capable to handle pushing such pre-header into
a packet without needing space pre-allocation like our SKB scheme
There is a general layering problem.
Upper levels which allocate the skb for transmit have no actual clue
regarding what lower level system their buffer will use when going out.
The (IPv4-)TCP code does allocate:
MAX_TCP_HEADER + 15 + tp->mss_cache
for each full outgoing frame.
There MAX_TCP_HEADER = 128 + MAX_HEADER
There MAX_HEADER = LL_MAX_HEADER + 48 (if IPv6 or IPIP support is defined)
= LL_MAX_HEADER + 0 (if neither of those)
And LL_MAX_HEADER = 96 (if with AX25)
= 48 (if no AX25, but have TokenRing)
= 32 (in all other cases)
Then happens tcp_alloc_skb() (which calls alloc_skb() plus does
assorted TCP related tricks), and after further TCP tricks, call
for skb_reserve(skb, MAX_TCP_HEADER) is done.
I really would like to see some mechanism by which we can register
(properly layered) those varying header fields without need to do
preprocessor gymnastics, like include/linux/netdevice.h has.
That is, when I push in VLAN support module, I could instantly get
4 extra bytes of hard-header-len into the upper layers. Best if
I would get that only for cases which are going out thru device
where those bytes would be added, and not "just in case" for all.
(That selective adding, of course, is layering violation.)