[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:23:48 -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>
Sender: owner-netdev@xxxxxxxxxxx
Richard Guy Briggs wrote:
> On Wed, Jun 13, 2001 at 09:15:40AM -0700, Ben Greear wrote:

> > In certain cases you may have to clone and grow the skb.  But, since that
> > is inneficient, you should only do that in wierd boundary cases at most,
> > and in general, you should make sure the skb has enough reserved space
> > from the beginning.  netdevice.h has some macro magic that figures out
> > the max-header (ie what to reserve).  If you can determine how much you
> > need, you can change it there...
> That doesn't help much if I need to add nested IPSec headers...

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


Ben Greear <greearb@xxxxxxxxxxxxxxx>          <Ben_Greear@xxxxxxxxxx>
President of Candela Technologies Inc

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