On Thu, 2011-09-08 at 18:28 +0200, K. Macy wrote: > > Whatever the mechanism is, the interface should allow for: > > > > - Flexible matching on layer 2, 3 and 4 header fields > > - Masking out some bits before matching (e.g. ignoring priority bits of > > VLAN tag or least significant bits of IPv4 address) > > - Priority of rules in case several match a single flow. This may > > need to be combined with location, since in a TCAM location may > > determine priority. > > - Requesting packets to be dropped, steered to a single RX queue, or > > steered to a range of RX queues (using a flow hash and indirection > > table) > > - Use of multiple hash indirection tables > > Do you feel that the Linux API for this is the right place to start > looking?
You can certainly learn from the mistakes made in Linux. :-) > Earlier you said: "The exact capabilities of the hardware > are all quite > different and we're still recovering from the early mistake of > defining two subtly different interfaces." Have the two APIs been > unified, if not which one do you believe is the "right" one? RX NFC is the right one. The other one (RX n-tuple) will be removed once I've converted the sfc driver to use RX NFC. It isn't flexible enough to cover the full matching capabilities and it doesn't allow for requesting steering + hashing, although I'm hoping to extend it to cover that later. Ben. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
