From: Alexander Duyck <alexander.h.duyck@intel.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: "Alexander Duyck" <alexander.duyck@gmail.com>,
"David Miller" <davem@davemloft.net>,
netdev <netdev@vger.kernel.org>,
"Neal Cardwell" <ncardwell@google.com>,
"Tom Herbert" <therbert@google.com>,
"Jeff Kirsher" <jeffrey.t.kirsher@intel.com>,
"Michael Chan" <mchan@broadcom.com>,
"Matt Carlson" <mcarlson@broadcom.com>,
"Herbert Xu" <herbert@gondor.apana.org.au>,
"Ben Hutchings" <bhutchings@solarflare.com>,
"Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi>,
"Maciej Żenczykowski" <maze@google.com>
Subject: Re: [PATCH 3/4 v2 net-next] net: make GRO aware of skb->head_frag
Date: Tue, 01 May 2012 09:17:35 -0700 [thread overview]
Message-ID: <4FA00C9F.8080409@intel.com> (raw)
In-Reply-To: <1335854378.11396.26.camel@edumazet-glaptop>
On 04/30/2012 11:39 PM, Eric Dumazet wrote:
> On Mon, 2012-04-30 at 22:33 -0700, Alexander Duyck wrote:
>
>> The question I had was more specific to GRO. As long as we have
>> skb->users == 1 and the skb isn't cloned we should be fine. It just
>> hadn't occurred to me before that napi_gro_receive had the extra
>> requirement that the skb couldn't be cloned.
>>
> OK
>
> By the way, even if skb was cloned, we would be allowed to steal
> skb->head.
>
> When we clone an oskb we :
>
> 1) allocate a struct nskb sk_buff (or use the shadow in case of TCP)
> 2) increment dataref
The problem I have is with this piece right here. So you increment
dataref. Now you have an skb that is still pointing to the shared info
on this page and dataref is 2. What about the side that is stealing the
head? Is it going to be tracking the dataref as well and decrementing
it before put_page or does it just assume that dataref is 1 and call
put_page directly? I am guessing the latter since I didn't see anything
that allowed for tracking the dataref of stolen heads.
> 3) link skb->head
>
> After cloning() nskb->users == 1, and oskb->users is unchanged
>
> I believe you are referring to skb_get(oskb), that ones increment
> oskb->users and skb_shared(oskb) then returns true.
skb_clone and skb_get are two completely separate things. My concern
with the skb_get portion is if skb->users is greater than 1 we should
not be freeing the skbuff back to the head cache. This was addressed
with the fact that GRO is requiring that skb->users be 1 before it is
handed the skb, although I didn't look too closely at the other patches
that are also stealing skb->head. My concern with skb_clone, as I
mentioned above, is that I am not sure how the dataref tracking will
still work.
It looks like Dave applied the patches last night so I will pull the
latest net-next and do some poking around. It is possible I am just
being dense and not getting this, but I just feel like there is
something that got missed or overlooked.
Thanks,
Alex
next prev parent reply other threads:[~2012-05-01 16:17 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-27 10:37 [PATCH 3/4 net-next] net: make GRO aware of skb->head_frag Eric Dumazet
2012-04-30 17:54 ` Eric Dumazet
2012-04-30 18:10 ` [PATCH 3/4 v2 " Eric Dumazet
2012-04-30 23:36 ` Alexander Duyck
2012-05-01 1:27 ` Eric Dumazet
2012-05-01 5:33 ` Alexander Duyck
2012-05-01 6:39 ` Eric Dumazet
2012-05-01 16:17 ` Alexander Duyck [this message]
2012-05-01 17:04 ` Eric Dumazet
2012-05-01 19:45 ` Alexander Duyck
2012-05-02 2:45 ` Eric Dumazet
2012-05-02 8:24 ` Eric Dumazet
2012-05-02 16:16 ` Alexander Duyck
2012-05-02 16:19 ` Eric Dumazet
2012-05-02 16:27 ` Eric Dumazet
2012-05-02 17:04 ` Alexander Duyck
2012-05-02 17:02 ` Alexander Duyck
2012-05-02 17:16 ` Rick Jones
2012-05-01 22:58 ` Alexander Duyck
2012-05-01 23:10 ` Alexander Duyck
2012-05-02 2:47 ` Eric Dumazet
2012-05-02 3:54 ` Eric Dumazet
2012-05-02 8:13 ` [PATCH net-next] net: take care of cloned skbs in tcp_try_coalesce() Eric Dumazet
2012-05-02 15:52 ` Alexander Duyck
2012-05-02 16:12 ` Eric Dumazet
2012-05-02 16:27 ` Alexander Duyck
2012-05-02 16:46 ` Eric Dumazet
2012-05-02 17:55 ` [PATCH v2 " Eric Dumazet
2012-05-02 19:58 ` [PATCH net-next] net: implement tcp coalescing in tcp_queue_rcv() Eric Dumazet
2012-05-02 20:11 ` Joe Perches
2012-05-02 20:23 ` Eric Dumazet
2012-05-02 20:34 ` Joe Perches
2012-05-03 0:32 ` David Miller
2012-05-03 1:11 ` David Miller
2012-05-03 2:14 ` Eric Dumazet
2012-05-03 2:21 ` David Miller
2012-05-03 1:11 ` [PATCH v2 net-next] net: take care of cloned skbs in tcp_try_coalesce() David Miller
2012-05-02 18:05 ` [PATCH " Alexander Duyck
2012-05-02 18:15 ` Eric Dumazet
2012-05-02 20:55 ` Alexander Duyck
2012-05-03 1:52 ` Eric Dumazet
2012-05-03 3:00 ` Alexander Duyck
2012-05-03 3:14 ` Eric Dumazet
2012-05-03 3:28 ` Alexander Duyck
2012-05-01 1:48 ` [PATCH 3/4 v2 net-next] net: make GRO aware of skb->head_frag David Miller
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=4FA00C9F.8080409@intel.com \
--to=alexander.h.duyck@intel.com \
--cc=alexander.duyck@gmail.com \
--cc=bhutchings@solarflare.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=herbert@gondor.apana.org.au \
--cc=ilpo.jarvinen@helsinki.fi \
--cc=jeffrey.t.kirsher@intel.com \
--cc=maze@google.com \
--cc=mcarlson@broadcom.com \
--cc=mchan@broadcom.com \
--cc=ncardwell@google.com \
--cc=netdev@vger.kernel.org \
--cc=therbert@google.com \
/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 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).