[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4ED491DC.8030304@intel.com>
Date: Tue, 29 Nov 2011 00:03:40 -0800
From: John Fastabend <john.r.fastabend@...el.com>
To: Eric Dumazet <eric.dumazet@...il.com>
CC: Dave Taht <dave.taht@...il.com>, Tom Herbert <therbert@...gle.com>,
"davem@...emloft.net" <davem@...emloft.net>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH v4 0/10] bql: Byte Queue Limits
On 11/28/2011 11:45 PM, Eric Dumazet wrote:
> Le lundi 28 novembre 2011 à 23:23 -0800, John Fastabend a écrit :
>
>> I wonder if we should consider enabling TSO/GSO per queue or per traffic
>> class on devices that support this. At least in devices that support
>> multiple traffic classes it seems to be a common usage case to put bulk
>> storage traffic (iSCSI) on a traffic class and low latency traffic on a
>> separate traffic class, VoIP for example.
>>
>
> It all depends on how device itself is doing its mux from queues to
> ethernet wire. If queue 0 starts transmit of one 64KB 'super packet',
> will queue 1 be able to insert a litle frame between the frames of queue
> 0 ?
>
Yes this works at least on the ixgbe supported 82599 device as you
would hope. 'super packets' from queues can and will be interleaved,
perhaps with standard sized packets, depending on the currently
configured arbitration scheme. So with multiple traffic classes we
can make a link strict 'low latency' class to TX frames as soon as
they are available.
Also I would expect this to work correctly on any of the coined
CNA devices, the bnx2x devices for example. I'll probably see what
can be done after finishing up some other things first.
--
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