Re: Allocation of sk_buffs in the kernel

[Jens Hoffrichter]

Ooops, this mail wasn't finished yet....pressed some wrong buttons at the
last mail ;))

> > I'm currently writing a kernel patch where it is essential to get
known>
> > when a sk_buff is allocated. Or better said I have to get known when a
> > sk_buff is effectively a new packet in the kernel-
>I don't want to guess why you need that...
I'm currently writing a stack profiler as my diploma thesis. It should give
a statistic how long a packet takes from one part of the network stack to
the other. So I have to watch the sk_buffs travelling through the kernel
and I need badly to know when they are allocated :) And, on top, the
deadline is in one week, and there are really strange things going on ;)

> > I currently identified 3 functions in the kernel where sk_buffs are
> > allocated: alloc_skb (of course), skb_linearize and pskb_expand_head.
Or at
> > least there new data is defined for the sk_buffs.
> >
> > Now I monitor a TCP session, a FTP download better said, and on the
> > interface arrives around 30000 packets for 50 MB of data. But in my
kernel
> > patch only 2000 packets are allocated, or at least I see only the
> > allocation of 2000 packets.
> >
> > Can anyone help me where I can find my missing packets? ;)) I need them
> > badly! *GG*

> There should be no skbuff allocation outside net/core/skbuff.c and all
> normal[1] networking drivers also don't use private pools. Perhaps
> you forgot to instrument a case there.
I have done some bit more testing yesterday, and the problem occurs in
either sending and receiving way, on two different ethernet drivers
(eepro100 and AMD Lance) and every where the same problem occurs: I see
only a fraction of the traffic (around 3 MBs at a 50 MB up/download) and
nearly the same fraction of packet buffers. I have profiling code in
skb_clone and I have no idea where to look anymore ;)

I don't think its because of drivers doing nasty things with sk_buffs,
because then the problem wouldn't occur in the transmitting case....

CU,
Jens