Date: Mon, 29 Jun 2015 18:05:41 +0200 From: Luigi Rizzo <rizzo@iet.unipi.it> To: Slawa Olhovchenkov <slw@zxy.spb.ru> Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> Subject: Re: netmap custom RSS and custom packet info Message-ID: <CA%2BhQ2%2BjhNkhLnxHQKeoEgbs2479hdnLd7mRR3XPmQLZyS1=1sw@mail.gmail.com> In-Reply-To: <20150629151750.GD1647@zxy.spb.ru> References: <20150629151750.GD1647@zxy.spb.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jun 29, 2015 at 5:17 PM, Slawa Olhovchenkov <slw@zxy.spb.ru> wrote: > Working with netmap and modern hardware I am lacking some features: > > a) some spare space before packet (64/128/192/256 bytes) for > application data. For example: application do some pre-analysig > packet, filled structure in this space and routed packet (via NETMAP > pipe) to other thread. Received thread got packet and linked > inforamtion about this packet for processing w/o additional overhead. > =E2=80=8Bspare space in front of the packet is something we have been considering for a different purpose, namely better support for encapsulation/decapsulation and things like vhost-net header. =E2=80=8BNote though that the annotation is transferred for free only in the case of pipes or ports sharing the same memory region; vale ports would have to explicitly copy the extra=E2=80=8B bytes which is (moderately) expensive. A quick and dirty way to support what you want is the following: - in the kernel code, modify NMB(), PNMB() and the offset between the netmap_ring and the first buffer to add the extra space you want in front of the packet. You can possibly make this offset a sysctl-controlled value - in netmap_vale.c, make a small change to the code that copies buffers so that it includes also the space before the actual packet. That should be all. > b) custom RSS. Modern NIC have RSS poorly interoperable with packet > analysing: packets from same flow, but different direction placed in > different queue, PPPoE encapsulated packets placed in queue 0, > different tunneling don't recognised and etc. May be NETMAP can be > used custom RSS hashing from loadable kernel module, provideng by > user? Function frm this module can be packet analysing, tunnel > removing, custom RSS hashnig with direction-independly maner, filled > some structure prepended to buffer (see above) and pass this > information to application. > =E2=80=8BRSS is completely orthogonal to=E2=80=8B =E2=80=8B netmap and I strongly suggest to keep it this way, using either use the NIC-specific tools to control RSS or some generic mechanism (on linux there is ethtool, and we should implement something similar also on freebsd). =E2=80=8Bcheers luigi =E2=80=8B > This is possible? This is useful not only to me? > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > --=20 -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2217533 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+-------------------------------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2BhQ2%2BjhNkhLnxHQKeoEgbs2479hdnLd7mRR3XPmQLZyS1=1sw>