On Sat, 13 Mar 2021 at 23:24, Özkan KIRIK <ozkan.ki...@gmail.com> wrote: > > Hello Adrian, > > I wonder if the current RSS code supports software mode. Is it possible to > enforce software RSS? And what about Sender Side Scaling ?
The current RSS code does enforce it on all the NICs, so if you enable it and you don't have hardware RSS then the kernel will rehash things in software for you. It has to support software RSS anyway because of how fragments work - NICs will only do 2-tuple hashing on fragments (as there's no port info in the fragment.) So, the received queue for the fragment doesn't match the received-queue for the first packet in the frame, and it ends up being reinjected correctly once the frame is fully received. > I want to assign a snort instance for each NIC queue. Snort is configured to > use netmap mode. Needs and questions are below: > - For a proper detection, both of request and response packets must enter > into same snort instance so that same NIC queue. For example 3way handshake > packets, TLS handshake packets and etc all must use same queue for both > directions. Then you need to use a symmetric RSS key! > - I'm afraid that, option RSS is only socket aware. But gateways/routers > doesnt have sockets for all connections. Is it possible to perform such > hashing and requeuing while forwarding packets? It's .. more complicated than that. > - On receive side, is it possible to hashing & requeuing before the netmap > step? > - On sender side, is it possible to hashing & queuing before pushing in NIC > queue? So, when I last left it (and what we were doing at Norse a few years ago) was: * using RSS * using a symmetric RSS key * Intel ixgbe 10GB, chelso 10GB/40GB NICs would then use the system RSS key and queue configuration. Now, notably I haven't hacked on this since then and it's possible something has crept in with the advent of iflib that may have messed this up - but my intention when fixing up RSS in FreeBSD was to continue using the notion that the whole "system" had an RSS key. All drivers and software hashing would all use the same key and tuple configuration where appropriate, so things would "just line up". Now, this isn't as flexible as the Linux way where you can configure it per-NIC but I wanted to avoid scenarios where you'd mess up the config and suddenly your traffic didn't work right at all. -adrian _______________________________________________ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
