[Top] [All Lists]

Re: skb_pull, etc. panics.

To: Richard Guy Briggs <rgb@xxxxxxxxxxxxxxxxxxxxx>
Subject: Re: skb_pull, etc. panics.
From: Ben Greear <greearb@xxxxxxxxxxxxxxx>
Date: Wed, 13 Jun 2001 15:42:24 -0700
Cc: Andi Kleen <ak@xxxxxx>, netdev@xxxxxxxxxxx
Organization: Candela Technologies
References: <20010606141145.L31244@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20010613032126.B5323@xxxxxxxxxx> <20010613115848.A19894@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <3B2791AC.7EAEC35A@xxxxxxxxxxxxxxx> <20010613182255.D19894@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <3B27E7F4.1D2BB21F@xxxxxxxxxxxxxxx> <20010613184952.P18366@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
Richard Guy Briggs wrote:
> On Wed, Jun 13, 2001 at 03:23:48PM -0700, Ben Greear wrote:

> > The 802.1Q vlan code I wrote has logic to grow the skb when needed,
> > you can look at it if you'd like:
> >
> > I'm guessing that if the header was deterministic before you started,
> > then you should be able to determine how much needed to be reserved
> > for the lower layers.  So, you can just make sure you have that much
> > space before sending it to the lower layers.  If you can determine
> > a reserve space that works, say, 90% of the time or better, then
> > you can change the netdevice.h macro accordingly, and then do copies
> > to make the skb bigger the other 10% of the time.  With memory as
> > cheap as it is, it may be perfectly reasonable to 'waste' 512 bytes
> > or whatever at the front of the skb in order to cut down on your copying
> > for the normal case.
> >
> > This could be configured at compile time, ie only enable it when ipsec is
> > enabled.
> It is not static.  It depends on the number of nestings.  It also
> depends on combinations of seperate AH, adding IPCOMP, tunnel mode,
> etc...

Is it normally under 512 bytes of overhead (please god let that be true!! :))
So reserve that in netdevice.h

Then just do checks each time you add layers.  If you have to copy/expand,
so be it (bump a counter so you can examine your performance tuning later.)

At your outer-most wrapper/layer, you will be sending it down the stack, right?

At that point, ensure (again), that you have enough space on the front of
the header for all lower layers (those layers' max usage is known, or the
current code would break).  If not, allocate more and copy again.  That at 
least should
be correct, even if it is somewhat innefficient.  As you better understand
your heuristics, then you can optimize your code to do less copies and/or
waste less memory for the common case.

I believe that the limiting factor will usually be bandwidth anyway,
so even a few extra ram->ram copies will probably not kill you, especially
with the ever increasing processing power available.
Ben Greear <greearb@xxxxxxxxxxxxxxx>          <Ben_Greear@xxxxxxxxxx>
President of Candela Technologies Inc

<Prev in Thread] Current Thread [Next in Thread>