[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHA+R7MJX3Du8ggOo2GqGA4rXvY30YOpCFqS4PBN2ZNE=kwKuA@mail.gmail.com>
Date: Wed, 27 Aug 2014 11:28:25 -0700
From: Cong Wang <cwang@...pensource.com>
To: David Miller <davem@...emloft.net>
Cc: netdev <netdev@...r.kernel.org>, Tom Herbert <therbert@...gle.com>,
Jamal Hadi Salim <jhs@...atatu.com>,
Hannes Frederic Sowa <hannes@...essinduktion.org>,
Eric Dumazet <edumazet@...gle.com>,
jeffrey.t.kirsher@...el.com, rusty@...tcorp.com.au,
Daniel Borkmann <dborkman@...hat.com>, brouer@...hat.com
Subject: Re: [PATCH 0/2] Get rid of ndo_xmit_flush
On Mon, Aug 25, 2014 at 4:34 PM, David Miller <davem@...emloft.net> wrote:
>
> Given Jesper's performance numbers, it's not the way to go.
>
> Instead, go with a signalling scheme via new boolean skb->xmit_more.
>
> This has several advantages:
>
> 1) Nearly trivial driver support, just protect the tail pointer
> update with the skb->xmit_more check.
>
> 2) No extra indirect calls in the non-deferral cases.
>
First of all, I missed your discussion at kernel summit.
Second of all, I am not familiar with hardware NIC drivers.
But for me, it looks like you are trying to pend some more packets
in a TX queue until the driver decides to flush them all in one shot.
So if that is true, doesn't this mean the latency of first packet pending
in this queue will increase and network traffic will be more bursty for
the receiver??
Also, even if this is a cool feature in hardware driver, doesn't it make
sense to allow users to disable it with ethtool?
It looks like this is still WIP, since no one really sets ->xmit_more to 1
in the code.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists