* Re: Allocation of sk_buffs in the kernel
[not found] <OF55D2E221.5E62CB41-ONC1256AB0.0052D2D3@de.ibm.com.suse.lists.linux.kernel>
@ 2001-08-23 3:14 ` Andi Kleen
2001-08-23 3:42 ` Arnaldo Carvalho de Melo
0 siblings, 1 reply; 8+ messages in thread
From: Andi Kleen @ 2001-08-23 3:14 UTC (permalink / raw)
To: Jens Hoffrichter; +Cc: linux-kernel
"Jens Hoffrichter" <HOFFRICH@de.ibm.com> writes:
> 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 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.
-Andi
[1] There may be a few unnormal ones that do; e.g. vendor driver
writers seem to frequently try to reuse skbuffs privately because they're
used to that from other OS. It is discouraged and somewhat tricky, but
possible.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Allocation of sk_buffs in the kernel
2001-08-23 3:14 ` Allocation of sk_buffs in the kernel Andi Kleen
@ 2001-08-23 3:42 ` Arnaldo Carvalho de Melo
0 siblings, 0 replies; 8+ messages in thread
From: Arnaldo Carvalho de Melo @ 2001-08-23 3:42 UTC (permalink / raw)
To: Andi Kleen; +Cc: Jens Hoffrichter, linux-kernel
Em Thu, Aug 23, 2001 at 05:14:56AM +0200, Andi Kleen escreveu:
> [1] There may be a few unnormal ones that do; e.g. vendor driver
> writers seem to frequently try to reuse skbuffs privately because they're
> used to that from other OS. It is discouraged and somewhat tricky, but
> possible.
The original 802.2 stack from procom, used frame_t all over the core stack,
with only the entry/exit points manipulating skb's. On entry from the core
networking stack and from upper protocols (NetBEUI in procom case) they
allocated a frame_t from a pool and initialited pointers to the mac and llc
headers and stored the skb type in another frame_t member, pointing to the
skb memory and used those pointers instead of skb->h and skb->nh. That
way, I think, they could use the core for several OSes.
Maybe Jens should use something like WAITQUEUE_DEBUG if he want to know
where alloc_skb and friends were called, see include/linux/wait.h 8)
- Arnaldo
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Allocation of sk_buffs in the kernel
2001-08-23 9:29 Jens Hoffrichter
@ 2001-08-23 9:46 ` Arnaldo Carvalho de Melo
0 siblings, 0 replies; 8+ messages in thread
From: Arnaldo Carvalho de Melo @ 2001-08-23 9:46 UTC (permalink / raw)
To: Jens Hoffrichter; +Cc: linux-kernel
Em Thu, Aug 23, 2001 at 11:29:11AM +0200, Jens Hoffrichter escreveu:
> > > > Maybe Jens should use something like WAITQUEUE_DEBUG if he want to
> know
> > > > where alloc_skb and friends were called, see include/linux/wait.h 8)
> > > Do you mean I should use something LIKE the WAITQUEUE_DEBUG (eg.
> > > implementing something like that in skbuff.c) or I should use
> > > WAITQUEUE_DEBUG?
> > no, just use the same idea that is used to debug wait_queues
> OK, then I interpreted the code in wait.h right ;)
>
> > > Are there any examples how to use the WAITQUEUE_DEBUG?
>
> > oops, I mean the __waker thing, for debugging you could get the address
> of
> > the caller with current_text_addr() and store it in an extra sk_buff
> field
> > so that later on you could know who create the skb.
> But where should I fill this field in the sk_buff? I know that alloc_skb
> creates an sk_buff, so this would be of no use for me. Or do you mean to
> add something like that to the initialization of the sk_buff struct, like a
> "long allocator = current_text_addr()" in skbuff.h? Is something like this
> possible? I'm not sure about it....
look, alloc_skb is not inline, so you need to use
__builtin_return_address(0) to know who called alloc_skb, you have to
change struct sk_buff to have an extra member where you will store the
return of __builtin_return_address(0), and possibly another field to store
the jiffies, so that you'll have the time when the alloc_skb was called,
then, later on, you could just printk the time it took from the alloc_skb
to the place where you want to know how long it took to traverse the
section of the network stack you're interested in.
> > About the example of WAITQUEUE_DEBUG:
> >
> > after being awaken you could do this:
>
> > dprintk("sleeper=%p, waker=%lx\n",
> > current_text_addr(), wait.__waker);
>
> > in a inline function does the trick, but this is just an example of a
> > function that uses an extra debug field in a structure that is alocated
> > somewhere and you want to know who allocated it later on.
>
> > Yes, you'll have to decode the address from syslog, gotcha?
> But the __waker member is filled by a macro from wait.h, if I had seen it
> right. Where would you issue such a dprintk call?
> Sorry about my missing knowledge about wait queues, but I don't get the
> point where to fill the member. That I could print it later on, thats
> clear, but how to fill it?
creating another field in the struct sk_buff, like I said above. The whole
point of the wait_queue was to show you the idea, the fact that you could
add another field to the struct you want to watch, see this excerpt from
include/linux/wait.h:
struct __wait_queue {
unsigned int flags;
#define WQ_FLAG_EXCLUSIVE 0x01
struct task_struct * task;
struct list_head task_list;
#if WAITQUEUE_DEBUG
long __magic;
long __waker;
#endif
};
see? you just add a 'long allocator; long jiffies_creation;' to struct
sk_buff like in the struct above, for WAITQUEUE_DEBUG debugging the kernel
has __magic and __waker, and store at alloc_skb time there the return of
__builtin_return_address(0) and jiffies, the later on you use it for your
purposes.
- Arnaldo
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Allocation of sk_buffs in the kernel
@ 2001-08-23 9:29 Jens Hoffrichter
2001-08-23 9:46 ` Arnaldo Carvalho de Melo
0 siblings, 1 reply; 8+ messages in thread
From: Jens Hoffrichter @ 2001-08-23 9:29 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo; +Cc: linux-kernel
> > > Maybe Jens should use something like WAITQUEUE_DEBUG if he want to
know
> > > where alloc_skb and friends were called, see include/linux/wait.h 8)
> > Do you mean I should use something LIKE the WAITQUEUE_DEBUG (eg.
> > implementing something like that in skbuff.c) or I should use
> > WAITQUEUE_DEBUG?
> no, just use the same idea that is used to debug wait_queues
OK, then I interpreted the code in wait.h right ;)
> > Are there any examples how to use the WAITQUEUE_DEBUG?
> oops, I mean the __waker thing, for debugging you could get the address
of
> the caller with current_text_addr() and store it in an extra sk_buff
field
> so that later on you could know who create the skb.
But where should I fill this field in the sk_buff? I know that alloc_skb
creates an sk_buff, so this would be of no use for me. Or do you mean to
add something like that to the initialization of the sk_buff struct, like a
"long allocator = current_text_addr()" in skbuff.h? Is something like this
possible? I'm not sure about it....
> About the example of WAITQUEUE_DEBUG:
>
> after being awaken you could do this:
> dprintk("sleeper=%p, waker=%lx\n",
> current_text_addr(), wait.__waker);
> in a inline function does the trick, but this is just an example of a
> function that uses an extra debug field in a structure that is alocated
> somewhere and you want to know who allocated it later on.
> Yes, you'll have to decode the address from syslog, gotcha?
But the __waker member is filled by a macro from wait.h, if I had seen it
right. Where would you issue such a dprintk call?
Sorry about my missing knowledge about wait queues, but I don't get the
point where to fill the member. That I could print it later on, thats
clear, but how to fill it?
CU,
Jens
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Allocation of sk_buffs in the kernel
2001-08-23 9:01 Jens Hoffrichter
@ 2001-08-23 9:12 ` Arnaldo Carvalho de Melo
0 siblings, 0 replies; 8+ messages in thread
From: Arnaldo Carvalho de Melo @ 2001-08-23 9:12 UTC (permalink / raw)
To: Jens Hoffrichter; +Cc: linux-kernel
Em Thu, Aug 23, 2001 at 11:01:42AM +0200, Jens Hoffrichter escreveu:
> Hi,
>
> > Maybe Jens should use something like WAITQUEUE_DEBUG if he want to know
> > where alloc_skb and friends were called, see include/linux/wait.h 8)
> Do you mean I should use something LIKE the WAITQUEUE_DEBUG (eg.
> implementing something like that in skbuff.c) or I should use
> WAITQUEUE_DEBUG?
no, just use the same idea that is used to debug wait_queues
> The code in wait.h mainly seems to consist of issuing BUG() calls, and
> thats not quite what I want to ;) But how is it to use? I don't know much
> about waitqueues in the Linux kernel, I mainly played with the network
> stack...
heh, thats my use for the waitqueue debug now 8)
> Are there any examples how to use the WAITQUEUE_DEBUG?
oops, I mean the __waker thing, for debugging you could get the address of
the caller with current_text_addr() and store it in an extra sk_buff field
so that later on you could know who create the skb.
About the example of WAITQUEUE_DEBUG:
after being awaken you could do this:
dprintk("sleeper=%p, waker=%lx\n",
current_text_addr(), wait.__waker);
in a inline function does the trick, but this is just an example of a
function that uses an extra debug field in a structure that is alocated
somewhere and you want to know who allocated it later on.
Yes, you'll have to decode the address from syslog, gotcha?
- Arnaldo
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Allocation of sk_buffs in the kernel
@ 2001-08-23 9:07 Jens Hoffrichter
0 siblings, 0 replies; 8+ messages in thread
From: Jens Hoffrichter @ 2001-08-23 9:07 UTC (permalink / raw)
To: Andi Kleen; +Cc: linux-kernel
> > 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Allocation of sk_buffs in the kernel
@ 2001-08-23 9:01 Jens Hoffrichter
2001-08-23 9:12 ` Arnaldo Carvalho de Melo
0 siblings, 1 reply; 8+ messages in thread
From: Jens Hoffrichter @ 2001-08-23 9:01 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo; +Cc: linux-kernel
Hi,
> Maybe Jens should use something like WAITQUEUE_DEBUG if he want to know
> where alloc_skb and friends were called, see include/linux/wait.h 8)
Do you mean I should use something LIKE the WAITQUEUE_DEBUG (eg.
implementing something like that in skbuff.c) or I should use
WAITQUEUE_DEBUG?
The code in wait.h mainly seems to consist of issuing BUG() calls, and
thats not quite what I want to ;) But how is it to use? I don't know much
about waitqueues in the Linux kernel, I mainly played with the network
stack...
Are there any examples how to use the WAITQUEUE_DEBUG?
CU,
Jens
^ permalink raw reply [flat|nested] 8+ messages in thread
* Allocation of sk_buffs in the kernel
@ 2001-08-22 15:10 Jens Hoffrichter
0 siblings, 0 replies; 8+ messages in thread
From: Jens Hoffrichter @ 2001-08-22 15:10 UTC (permalink / raw)
To: linux-kernel
Hello everyone,
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 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*
It's not quite easy to look into the TCP code, because its quite big and a
bit complicated.....
Thanks in advance!
Regards,
Jens
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2001-08-23 9:47 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <OF55D2E221.5E62CB41-ONC1256AB0.0052D2D3@de.ibm.com.suse.lists.linux.kernel>
2001-08-23 3:14 ` Allocation of sk_buffs in the kernel Andi Kleen
2001-08-23 3:42 ` Arnaldo Carvalho de Melo
2001-08-23 9:29 Jens Hoffrichter
2001-08-23 9:46 ` Arnaldo Carvalho de Melo
-- strict thread matches above, loose matches on Subject: below --
2001-08-23 9:07 Jens Hoffrichter
2001-08-23 9:01 Jens Hoffrichter
2001-08-23 9:12 ` Arnaldo Carvalho de Melo
2001-08-22 15:10 Jens Hoffrichter
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).