Call for testing: netmap on 20.7

[heresjody]

This is correct. Opnsense notices a different kernel than the 20.7.3 kernel so it sees it as an "update".

[the-mk]

thanks... so even if I lock the kernel in the packages tab and perform a check for updates, it still insists on updating the kernel.
besides that, does it decide to update the kernel based on "I am different than stock" or "I am older than the stock"?

[heresjody]

Different than stock.

[allebone]

For those who

• are using Suricata/Sensei on VLANs on em(4)
• experiencing vmx crash
• experiencing vtnet crash
• want to have Suricata on PPPoE / OpenVPN interfaces

I have an (unofficial) test kernel ready. Please PM me if you'd like to give it a try.

PS: vmx patch fixes the kernel crash, but has an outstanding issue. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248494

Hi there is it still possible to get/test suricata with PPPoE WAN?

[mb]

Hi @allebone,

tun(4) support is now in 20.7.4. It seems it's not working as expected for PPPoE. We're on it.

[allebone]

Hi @allebone,

tun(4) support is now in 20.7.4. It seems it's not working as expected for PPPoE. We're on it.

Thank you :)

@bunchofreeds

[bunchofreeds]

Thanks @allebone and @mb

Just had to ask in the right place :)

[tcpip]

Hello @mb,

are there still issues with netmap on lagg interfaces with vlans on current 20.7.4 kernel? I'm using Sensei on a lagg interface with vlan child interfaces on igb nics. According to the spreadsheet this is a "PASS". However, from time to time my firewall becomes completely unreachable from the inside. This also happens sometimes when opening Sensei configuration pages. Often the situation stabilizes itself after a few minutes but sometimes I need to restart the whole firewall or unplug lagg members until it becomes reachable again. If in working state the issue can be observed by unplugging lagg member interfaces and starting to generate traffic while running a ping. The firewall becomes unreachable after a few seconds. If I disable Sensei this behaviour can't be observed - everything seems to work as expected from an lacp configuration.

Thanks!

[tcpip]

I configured Sensei to use the physical interfaces (igb) in the lagg now. Seems to work a lot better so far! Unplugging the cables doesn't cause any unavailability anymore.

[franco]

There is a new test kernel available, mostly for ix/ixl performance issues in iflib/netmap:

# opnsense-update -kr 20.7.4-next
# opnsense-shell reboot

You can see the relevant batch of new commits on the master branch[2].


Cheers,
Franco

[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248652
[2] https://github.com/opnsense/src/commits/master

[gauthig]

New kernel (20.7.4-next) helps ix 10G cards but some very strange results, seems like each thread has a cap but does parallel process much better.

20.7.4
IDS off  (CPU shows around 5%)
Send
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-5.00   sec  3.41 GBytes  5.85 Gbits/sec    0           
Receive (-R)
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.14  sec  4.42 GBytes  3.74 Gbits/sec    0           

IDS On - Hyperscan (CPU  40 - 50%)
Send
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-5.00   sec   742 MBytes  1.25 Gbits/sec    0
Receive (-R)
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-5.14   sec   455 MBytes   742 Mbits/sec    0

20.7.4-next
IDS off  (CPU shows around 30%)
Send
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  5.17 GBytes  4.44 Gbits/sec    0
Receive (-R)
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.13  sec  2.45 GBytes  2.08 Gbits/sec    0

IDS On - Hyperscan (CPU  60 - 80%)
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-60.00  sec  16.1 GBytes  2.30 Gbits/sec
Receive (-R)
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.13  sec  2.43 GBytes  2.06 Gbits/sec    0

But running iperf3 in parallel mode to simulate real multiple streams, it really picks up performance.  In previous kernel sum of parallel was about the same as 1 stream.
20.7.4
IDS On  (CPU shows around 80%)
Send + Parallel 10 (-P 10)
[ ID] Interval           Transfer     Bitrate         Retr
[SUM]   0.00-10.13  sec  7.79 GBytes  6.61 Gbits/sec
Receive (-R) + Parallel 10 (-P 10)

Almost same results for Receive and only about 10% less than with IDS Off.

Overall results with this kernel on an ix 10G interface
1) Double speed increase with netmap enabled
2) Multiple connections increase total throughput
3) New kernel with ix interface - CPU spikes way up both with and without netmap.  Note, if network throughput  is under 1g, then CPU stays around 5%, only when going over 1g does the CPU start to take a hit.

[franco]

Thanks for taking the time to crunch some numbers here! :)

The patch is an "iflib" patch which means it also changes non-netmap behaviour and the changes in bulk handling for ix(l) certainly require further tweaking as per the comments in FreeBSDs bug tracker, but this is good enough to merge and then wait for more patches on the subject to land in the tree.

I asked for additional results by Sunny Valley, particularly on re(4) and vmxnet3(4). And either Murat or me will follow up here in a bit.


Cheers,
Franco

[gauthig]

Not going to post all the detail stats but the 20.7.6 updated kernel performs slightly less than the 20.7.4-next kernel on the ix 10G cards.   I am getting about 1.5gbs. 

Please let me know when an updated kernel is available, but I know you are awaiting the BSD code to drop.

[franco]

Expected. 20.7.6 does not include ix(l) specific patching from 20.7.4-next.


Cheers,
Franco

[gauthig]

Hi Franco, does 20.7.4-next work with the 20.7.6 release?   If so I can install it?  But as per the other thread (no traffic monitoring), it's both 20.7.4-next and 20.7.6.   Traffic works fine with 20.7.4 base kernel. 

One item I have noticed since 20.7, ix(i) and vmxnet take a lot of cpu in heavy loads as compared to 20.1.   But most of that is all the Harden BSD 12 code and not opnsense.