netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Or Gerlitz <ogerlitz@mellanox.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: "David S. Miller" <davem@davemloft.net>,
	Linux Netdev List <netdev@vger.kernel.org>,
	Matan Barak <matanb@mellanox.com>,
	Amir Vadai <amirv@mellanox.com>,
	Saeed Mahameed <saeedm@mellanox.com>,
	Shani Michaeli <shanim@mellanox.com>,
	Ido Shamay <idos@mellanox.com>
Subject: Re: [PATCH net-next 5/8] net/mlx4_en: Remove redundant code from RX/GRO path
Date: Sun, 2 Nov 2014 16:09:22 +0200	[thread overview]
Message-ID: <54563B12.1040905@mellanox.com> (raw)
In-Reply-To: <1414770362.27538.7.camel@edumazet-glaptop2.roam.corp.google.com>

On 10/31/2014 5:46 PM, Eric Dumazet wrote:
> On Fri, 2014-10-31 at 16:00 +0200, Or Gerlitz wrote:
>> On Fri, Oct 31, 2014 at 5:19 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>>> On Fri, 2014-10-31 at 01:25 +0200, Or Gerlitz wrote:
>>>> On Thu, Oct 30, 2014 at 9:00 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>>>>> On Thu, 2014-10-30 at 18:06 +0200, Or Gerlitz wrote:
>>>>>> Remove the code which goes through napi_gro_frags() on the RX path,
>>>>>> use only napi_gro_receive().
>>>>> Hmpff... napi_gro_frags() should be faster. Have you benchmarked this ?
>>>>
>>>> yep we did, napi_gro_frags() was somehow better for single stream. Do
>>>> you think we need to do it the other way around, e.g converge to use napi_gro_frags()?
>>> napi_gro_frags() is faster because the napi->skb is reused fast (not
>>> going through kfree_skb()/alloc_skb() for every fragment)
>> I see. Is this a strong vote to convert the code to use napi_gro_frags
>> on it's usual track?
> I don't know yet. In some cases, actually slowing down the rx path can
> help by building bigger GRO packets. But instead of inserting delays,
> we can simply force napi to be run another time, with a nanosec based
> timer.
>
> I've tested this kind of heuristic :
>
>         /* If some packets are waiting in GRO engine and timeout is not expired,
>          * reschedule a NAPI poll. We allow servicing other softirqs
>          * before repoll, we do not rearm CQ.
>          */
>         if (rx_nsecs && napi->gro_list && !need_resched()) {
>                 u64 now = local_clock();
>                 unsigned long flags;
>
>                 /* If we got packets in this round, restart timeout */
>                 if (done)
>                         cq->tstart = now;
>                 else if (now - cq->tstart >= (u64)rx_nsecs)
>                         goto complete;
>
>                 /* Since we might need one skb very soon, build it now */
>                 napi_get_frags(napi);
>
>                 local_irq_save(flags);
>                 list_del(&napi->poll_list);
>                 __napi_schedule_irqoff(napi);
>                 local_irq_restore(flags);
>
>          } else {
> complete:
>                  napi_complete(napi);
>                  mlx4_en_arm_cq(priv, cq);
>          }
> 	return done;

Hi Eric,

For the time being, I'll drop from this series thischange and the 
following ones which depend on it. So can pick in the earlier patches of 
the series, and investigate in parallel thevarious optionsw.r.t GRO here.

Or.

  reply	other threads:[~2014-11-02 14:09 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-30 16:06 [PATCH net-next 0/8] Mellanox ethernet driver update Oct-30-2014 Or Gerlitz
2014-10-30 16:06 ` [PATCH net-next 1/8] net/mlx4_core: Prevent VF from changing port configuration Or Gerlitz
2014-10-30 16:06 ` [PATCH net-next 2/8] net/mlx4_core: Protect port type setting by mutex Or Gerlitz
2014-10-30 16:06 ` [PATCH net-next 3/8] net/mlx4_en: Remove RX buffers alignment to IP_ALIGN Or Gerlitz
2014-10-30 16:06 ` [PATCH net-next 4/8] net/mlx4_en: Add __GFP_COLD gfp flags in alloc_pages Or Gerlitz
2014-10-30 17:15   ` Eric Dumazet
2014-10-30 22:49     ` Or Gerlitz
2014-10-30 16:06 ` [PATCH net-next 5/8] net/mlx4_en: Remove redundant code from RX/GRO path Or Gerlitz
2014-10-30 19:00   ` Eric Dumazet
2014-10-30 23:25     ` Or Gerlitz
2014-10-31  3:19       ` Eric Dumazet
2014-10-31 14:00         ` Or Gerlitz
2014-10-31 15:46           ` Eric Dumazet
2014-11-02 14:09             ` Or Gerlitz [this message]
2014-11-02 14:28               ` Eric Dumazet
2014-10-30 16:06 ` [PATCH net-next 6/8] net/mlx4_core: Add retrieval of CONFIG_DEV parameters Or Gerlitz
2014-10-30 16:06 ` [PATCH net-next 7/8] net: Add calaulation of non folded IPV6 pseudo header checksum Or Gerlitz
2014-10-30 16:25   ` David Laight
2014-10-30 16:32     ` Or Gerlitz
2014-10-30 16:39       ` David Laight
2014-10-30 16:54         ` Or Gerlitz
2014-10-30 16:55           ` Or Gerlitz
2014-10-30 17:09           ` David Laight
2014-10-30 16:06 ` [PATCH net-next 8/8] net/mlx4_en: Extend checksum offloading by CHECKSUM COMPLETE Or Gerlitz
2014-10-30 18:22   ` Eric Dumazet
2014-10-30 21:20   ` Jerry Chu
2014-10-30 23:28     ` Or Gerlitz
2014-10-30 23:53       ` Jerry Chu
2014-10-30 23:59   ` Tom Herbert
2014-10-31 13:57     ` Or Gerlitz
2014-10-31  0:38   ` Yann Ylavic
2014-10-31 13:52     ` Or Gerlitz

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=54563B12.1040905@mellanox.com \
    --to=ogerlitz@mellanox.com \
    --cc=amirv@mellanox.com \
    --cc=davem@davemloft.net \
    --cc=eric.dumazet@gmail.com \
    --cc=idos@mellanox.com \
    --cc=matanb@mellanox.com \
    --cc=netdev@vger.kernel.org \
    --cc=saeedm@mellanox.com \
    --cc=shanim@mellanox.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).