lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
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