From: Willy Tarreau <w@1wt.eu>
To: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: netdev@vger.kernel.org,
	Gregory CLEMENT <gregory.clement@free-electrons.com>,
	Eric Dumazet <edumazet@google.com>
Subject: Re: [PATCH] net: convert mvneta to build_skb()
Date: Fri, 5 Jul 2013 10:09:59 +0200	[thread overview]
Message-ID: <20130705080959.GD25188@1wt.eu> (raw)
In-Reply-To: <20130705095038.018de378@skate>
On Fri, Jul 05, 2013 at 09:50:38AM +0200, Thomas Petazzoni wrote:
> > In practice we don't really need to store the frag_size in the struct, we
> > just need to know if the data were allocated using netdev_alloc_frag()
> > or kmalloc() to know how to free them. So a single bit would be enough,
> > and I thought about just doing a +1 on the pointer when we need to free
> > using kmalloc(). But that would add unneeded extra work in the fast path
> > to fix the pointers. And since we need to pass frag_size to build_skb()
> > it was a reasonable solution in my opinion.
> 
> Aah, okay makes sense. So now, the question that comes up is why this
> skb_size calculation is done in every call of mvneta_rx_refill() ? It
> should be computed once, at the same time pkt_size is calculated, and
> stored in the mvneta_port structure? Then you just need to test whether
> it is smaller or larger than PAGE_SIZE to decide whether to use
> netdev_alloc_frag() vs. kmalloc().
> 
> I.e, I would turn all the:
> 
> 	if (pp->frag_size)
> 		...
> 	else
> 		...
> 
> into:
> 
> 	if (pp->skb_size <= PAGE_SIZE)
> 		...
> 	else
> 		...
I was concerned by the same thing and saw that tg3 does the same. Then
I realized that we're only using constants here, so there isn't much
calculation (basically it's skb_size = pkt_size + something). However
it would probably make the code less confusing, especially if we were
two different readers concerned about this frag_size not changing per
packet.
> Of course, you can always hide this test behind a small macro or inline
> function, to make it something like:
> 
> 	if (mvneta_uses_small_skbs(pp))
> 		...
> 	else
> 		...
> 
> A better name than mvneta_uses_small_skbs() would of course be useful.
> 
> > > For example, in mvneta_rx_refill(), you store the skb_size in
> > > pp->frag_size, and then you later re-use it in mvneta_rxq_drop_pkts.
> > > What guarantees you that mvneta_rx_refill() hasn't be called in the
> > > mean time for a different packet, in a different rxq, for the same
> > > network interface, and the value of pp->frag_size has been overridden?
> > 
> > It's not a problem since the refill() applies pp->pkt_size which doesn't
> > change between calls. It's only changed in mvneta_change_mtu() which
> > first stops the device. So I think it's safe.
> 
> Yeah, sure, now that I see that pp->frag_size is constant for a given
> MTU configuration, it looks safe. But I find the current code that
> retests and reassigns pp->frag_size at every call of rxq_refill() to be
> very confusing.
Yes I agree. I think I'll experiment with the +/-1 on the pointer to
see the impact on the rest of the code, because probably that with a
few macros we could make that more transparent this way.
Best regards,
Willy
next prev parent reply	other threads:[~2013-07-05  8:10 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-04 17:35 [PATCH] net: convert mvneta to build_skb() Willy Tarreau
2013-07-04 21:31 ` David Miller
2013-07-04 22:12   ` Willy Tarreau
2013-07-05  7:17 ` Thomas Petazzoni
2013-07-05  7:43   ` Willy Tarreau
2013-07-05  7:50     ` Thomas Petazzoni
2013-07-05  8:09       ` Willy Tarreau [this message]
2013-07-15 14:34 ` Thomas Petazzoni
2013-07-15 15:12   ` Willy Tarreau
2013-07-15 15:23     ` Thomas Petazzoni
2013-07-15 15:30       ` Willy Tarreau
2013-07-15 15:35         ` Thomas Petazzoni
2013-07-15 15:52           ` Florian Fainelli
2013-07-15 17:01             ` Willy Tarreau
2013-07-15 19:44             ` Thomas Petazzoni
2013-07-15 23:02               ` Florian Fainelli
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=20130705080959.GD25188@1wt.eu \
    --to=w@1wt.eu \
    --cc=edumazet@google.com \
    --cc=gregory.clement@free-electrons.com \
    --cc=netdev@vger.kernel.org \
    --cc=thomas.petazzoni@free-electrons.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).