[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1412080721.30721.72.camel@edumazet-glaptop2.roam.corp.google.com>
Date: Tue, 30 Sep 2014 05:38:41 -0700
From: Eric Dumazet <eric.dumazet@...il.com>
To: Florian Westphal <fw@...len.de>
Cc: Jesper Dangaard Brouer <brouer@...hat.com>, netdev@...r.kernel.org,
"David S. Miller" <davem@...emloft.net>,
Tom Herbert <therbert@...gle.com>,
Hannes Frederic Sowa <hannes@...essinduktion.org>,
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: [net-next PATCH V5] qdisc: bulk dequeue support for qdiscs with
TCQ_F_ONETXQUEUE
On Tue, 2014-09-30 at 14:25 +0200, Florian Westphal wrote:
> You're right, but this is not related to this patch specifically.
> But sure, we can look into moving validate_xmit_skb calls outside of the
> qdisc root locked sections.
Yes please.
>
> > 2) TSO support. Have you ideas how to perform this ?
>
> Yes, the idea was to just remove the skb_is_gso() test and limit
> dql_avail() result to e.g. 128k to avoid a '8-fat-gso-skbs-in-a-row' scenario.
Really I think you are mistaken about GSO/TSO being fat skb. This is not
a qdisc concern, but packets producer. Think of TSO autosizing which
already takes care of this.
>
> Did you have any other ideas in mind?
I guess my question was more like : Should I wait you sending patches,
or should I do this ?
We are approaching merge window, and I would like to get this sorted out
for linux-3.18
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