All of lore.kernel.org
 help / color / mirror / Atom feed
From: Claude Robitaille <clauder@accedian.com>
To: netdev@vger.kernel.org
Subject: Re: sk_buff handling in packet handler
Date: Tue, 19 May 2009 18:41:28 -0400	[thread overview]
Message-ID: <4A133598.80405@accedian.com> (raw)
In-Reply-To: <20090517102548.0a55d5bd.ipng@69706e6720323030352d30312d31340a.nosense.org>

[-- Attachment #1: Type: text/plain, Size: 2215 bytes --]

Thanks Mark, very helpful

But I still  have some questions.

I see that you are using sbk_share_check, which will create a clone if 
the sk_buff is already used by someone else. In most cases the skb is 
not shared and the function simply return the same pointer without any 
modification to the original skb (in particular skb->users stays at 1). 
You  then manipulate the  sk_buff  (in particular  adding a MAC header, 
etc.) and eventually transmit the packet using dev_queue_xmit. The 
sk_buff will be ultimately kfree_skb by the NIC driver (or by you if an 
error occured somewhere before dev_queue_xmit).

My questions are:

- after you are done, net_rx_action may pass the sk_buff, modified by 
ectp_rcv, to other packet handler. How will other packet handlers know 
that, if they need to manipulate the sk_buff, they must create a clone? 
skb->users is still set to 1
- I presume that net_rx_action must also kfree the sk_buff, particularly 
if no packet handler decides to grab the packet. But it should not free 
it if it is still in the transmit queue, waiting for the HW to transmit 
it. But since nothing in the sk_buff tell net_rx_action that the packet 
is pending transmission how could this be the case? dev_queue_xmit does 
not appear to increase users (I used printk in another module to check 
this before and after calling dev_queue_xmit but it might be that my 
idle system is too fast for the printk to catch skb->users going to 2). 
In any case, I try to use sk_get (and 1 x kfree_skb) in my packet 
handler but I end up consuming all the memory in the system, presumably 
due to the fact that the sk_buff never get freed completely. What should 
be the correct way of handling this?

Claude

Mark Smith wrote:
> Hi Claude,
>
> You could have a look at my Ethernet Configuration Testing Protocol
> (ECTP) implementation. I followed what other protocols did regarding
> packet/skb handling, and also tried to make it very clear what was
> required, as I struggled a bit with similar issues that you are. The
> routine to start with is ectp_rcv().
>
> http://lwn.net/Articles/330797/
>
> Regards,
> Mark.
>
>   

-- 
Claude Robitaille
CTO
Accedian Networks
514-764-0119
clauder@accedian.com


[-- Attachment #2: clauder.vcf --]
[-- Type: text/x-vcard, Size: 176 bytes --]

begin:vcard
fn:Claude Robitaille
n:Robitaille;Claude
email;internet:clauder@accedian.com
tel;work:514-764-0119
tel;cell:514-796-7225
x-mozilla-html:TRUE
version:2.1
end:vcard


  parent reply	other threads:[~2009-05-19 22:41 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-17  0:55 sk_buff handling in packet handler Mark Smith
2009-05-17 17:23 ` Claude Robitaille
2009-05-18  5:38   ` Stephen Hemminger
2009-05-19 22:41 ` Claude Robitaille [this message]
  -- strict thread matches above, loose matches on Subject: below --
2009-05-16 16:31 Claude Robitaille
2009-05-16 20:19 ` Evgeniy Polyakov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A133598.80405@accedian.com \
    --to=clauder@accedian.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.