netdev - Re: [PATCH 0/4] [Net] Support Xen accelerated network plugin modules

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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