Matti Aarnio wrote:
>
> 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.)
So, you get a pkt coming in, and then add a protocol, then then try to
egress the pkt over the new protocol. It's now the wrong size, because it was
created before
the proto was initialized.
This isn't too likely to happen, perhaps...but it would still require
a lot of defensive coding that may not currently be in place.
> 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.
What does this really gain you?
More efficient use of memory? (Perhaps, but not much I think...)
Performance? (I doubt it, can someone offer an argument in favor?)
I don't think it's simpler, though it may make that one particular
place in netdevice.h cleaner.
> 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.
Chopping up your memory into blocks (which means allocating each block, right?)
does not seem any more efficient that just leaving adequate space at the
beginning of the skb, as is possible now. It would probably suck as far as
the cache is concerned too...
Ben
--
Ben Greear (greearb@xxxxxxxxxxxxxxx) http://www.candelatech.com
Author of ScryMUD: scry.wanfear.com 4444 (Released under GPL)
http://scry.wanfear.com http://scry.wanfear.com/~greear
|