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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 21 May 2007 11:18:40 +0100 From: Kieran Mansley <kmansley@...arflare.com> To: Herbert Xu <herbert@...dor.apana.org.au> Cc: Jeff Garzik <jgarzik@...ox.com>, Stephen Hemminger <shemminger@...ux-foundation.org>, xen-devel@...ts.xensource.com, netdev@...r.kernel.org, muli@...ibm.com Subject: Re: [PATCH 0/4] [Net] Support Xen accelerated network plugin modules On Mon, 2007-05-21 at 18:14 +1000, Herbert Xu wrote: > On Fri, May 18, 2007 at 02:15:48PM +0100, Kieran Mansley wrote: > > This set of patches provides the hooks and support necessary for > > accelerated network plugin modules to attach to Xen's netback and > > netfront. These modules provide a fast path for network traffic where > > there is hardware support available for the netfront driver to send and > > receive packets directly to a NIC (such as those available from > > Solarflare). > > The RX side looks reasonble. For TX, what sort of conditions are you > likely to use to decide whether a packet gets fast path or not? For us, at the moment, we TX-fast-path packets to MAC addresses that we would also RX-fast-path from. i.e. Those for which we have a filter in the NIC for. This boils down to a hash table lookup on the MAC addresses. We do a couple of other checks too (make sure it's IPV4, TCP or UDP, unicast) to keep things simple. > Also for TX, you'll need a better way of managing queue stopping/starting > since presumably you only want to wake the queue when both fast path and > slow path have free slots. Hmm, good point. At the moment the queue is stopped if either fast or slow path is busy, and restarted if either fast or slow path becomes not-busy. I suppose this would work OK if we could guarantee that the slow path wouldn't restart the queue that had been stopped by the fast path, and vice versa, but at the moment that's not the case, so you're right it needs looking at. Kieran - 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