[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1411167175.26859.55.camel@edumazet-glaptop2.roam.corp.google.com>
Date: Fri, 19 Sep 2014 15:52:55 -0700
From: Eric Dumazet <eric.dumazet@...il.com>
To: Cong Wang <cwang@...pensource.com>
Cc: Jesper Dangaard Brouer <brouer@...hat.com>,
netdev <netdev@...r.kernel.org>,
"David S. Miller" <davem@...emloft.net>,
Tom Herbert <therbert@...gle.com>,
Hannes Frederic Sowa <hannes@...essinduktion.org>,
Florian Westphal <fw@...len.de>,
Daniel Borkmann <dborkman@...hat.com>,
Jamal Hadi Salim <jhs@...atatu.com>,
Alexander Duyck <alexander.duyck@...il.com>,
John Fastabend <john.r.fastabend@...el.com>,
Dave Taht <dave.taht@...il.com>, toke@...e.dk
Subject: Re: [RFC net-next PATCH V3 0/2] qdisc bulk dequeuing and utilizing
delayed tailptr updates
On Fri, 2014-09-19 at 15:39 -0700, Cong Wang wrote:
> Then why commits like this one?
>
> commit 7070ce0a6419a118842298bc967061ad6cea40db
> Author: Alexander Duyck <alexander.h.duyck@...el.com>
> Date: Sat Sep 28 06:00:37 2013 +0000
>
> i40e: Add support for Tx byte queue limits
>
> Implement BQL (byte queue limit) support in i40e.
>
Read again my full mail, don't jump into conclusions in the middle of
it.
>
> >
> > If a device driver do nothing about BQL, byte_queue_limits/limit will be
> > zero by default.
See here ? Its all explained. If a device driver do not implement BQL,
limit will be zero, and bulk dequeue will _automatically_ be disabled.
BQL has no 'cost' if a driver does not use it.
Its basically fields which will never be updated.
(cf in struct netdev_queue :
struct dql dql;
)
>
> Also note that for some virtual device, BQL may make no sense at all,
> at least veth doesn't even use a TX queue (I know it has tx-0 mostly for
> qdisc). Perhaps all NETIF_F_LLTX ones?
Lets focus on the normal cases, where virtual devices do not have any
qdisc.
We are talking here of _qdisc_ bulk dequeue, right ?
--
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