On Mon, Oct 23, 2000 at 09:16:35AM -0700, Ben Greear wrote:
...
> > 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.)
>
> You need the outgoing pkt length, which means you must know your device
> at the time you allocate the SKB. That doesn't really seem feasible to me.
> (Routing, bridging, pkt-filtering, all make 'routing' decisions after the
> SKB has been created...)
Indeed. That is why I used term "layering violation"...
What I do think is worth considering:
Have the LL_MAX_HEADER replaced with a global integer, and
adding support for some protocol (registering a protocol in)
would be allowed to (with a spinlock?) increment the value
in there. (It is "a read-a-lot, modify rarely", after all,
thus having ATOMIC access there is serious waste of cycles.)
Thus e.g. IPv6 activation would push in its own additional
48 byte reservation into the pile for L3 use. (Perhaps
the TCP frame allocation should be split into IPv4 and IPv6
versions with appropriate max sizes for IP and TCP,
respectively.)
Because all frames can not be added on top of each other,
some smarter way to stack them would be nice for easier
protocol plugin registration.
Layer 2:
ENET - type/NSAP [ - VLAN ] - ...
ENET [ - VLAN ] - type/NSAP - ...
TR - NSAP [ - VLAN ] - ...
FDDI - NSAP [ - VLAN ] - ...
HDLC [ - PPP / CISCO HDLC ] - ...
AX25 ...
PPP ...
FrameRelay - NSAP - bridged-ENET - ...
ATM-AAL5 - PPP - ...
ATM-AAL5 - NSAP - PPP ...
Layer 3:
IPv4 - TCP/UDP/ICMP
IPv6 - TCP/UDP/ICMP
...
During initialization each subsystem would register how much they
need header space each, and the registration routine would go
thru the entire registered facility space, adding up stackable
chains at each level remembering maximums.
The final allocation space at L3 would then be the sum of Layer 2
and Layer 3 maximums (maybe, maybe not..)
Thinking more of it, there propably should be two integers,
one for use at Layer2 receivers, which would be used to reserve
space into beginning of the frame so that of it becomes bridged
(or routed) to other Layer2 device, there would be space for it.
(For example: PPP framed IP packet coming in and going out
thru FDDI NSAP frames, or thru AX25 UI frames.)
The more I think of these, the more I think we need to start
supporting MBUF-like block chains. Their uses should be
seriously deprecated and most commonly used protocols and frames
should still use pre-allocation of "hard header", but rarer
things could do chains.
> Ben
> --
> Ben Greear (greearb@xxxxxxxxxxxxxxx) http://www.candelatech.com
/Matti Aarnio
|