Messages

Removed the question.  Sorry, lack of caffeine.  It's working great on 21.7.4.  Thank you for the work as always!

Just curious as it's been a while since this was initially posted for testing.  Will this eventually be rolled into an upcoming point release soon or an updated kernel with the latest changes in the repo?

Thank you so much for the fort and work you guys do!

Same thing here with the kernel.  No matter what you type in, it will append -rss to the name.  Looking at the verbose output it's saying that it's trying to download from the sets folder but when I look on every mirror, these kernels are in the snapshots folder.  Not sure if they were removed?  Due to this I'm getting a no valid signature error.

Does anyone know if there is a way to change the policy on the ip6 protocol from flow to cpu?  That is the difference I notice in some of the previous posts.  Thinking this may be why I'm not getting RSS on ip6.

ix also seems to have support for RSS, passed through my other 10G card to OPNsense.

Code Select Expand

ix0: <Intel(R) X520 82599ES (SFI/SFP+)> port 0xf020-0xf03f mem 0xfd600000-0xfd67ffff,0xfd680000-0xfd683fff irq 10 at device 17.0 on pci0
ix0: Using 2048 TX descriptors and 2048 RX descriptors
ix0: Using 4 RX queues 4 TX queues
ix0: Using MSI-X interrupts with 5 vectors
ix0: allocated for 4 queues
ix0: allocated for 4 rx queues
ix0: Ethernet address: ***
ix0: PCI Express Bus: Speed 5.0GT/s Width x8
ix0: Error 2 setting up SR-IOV
ix0: netmap queues/slots: TX 4/2048, RX 4/2048

root@OPNsense:~ # sysctl -a | grep rss
net.inet.rss.bucket_mapping: 0:0 1:1 2:2 3:3 4:0 5:1 6:2 7:3
net.inet.rss.enabled: 1
net.inet.rss.debug: 0
net.inet.rss.basecpu: 0
net.inet.rss.buckets: 8
net.inet.rss.maxcpus: 64
net.inet.rss.ncpus: 4
net.inet.rss.maxbits: 7
net.inet.rss.mask: 7
net.inet.rss.bits: 3
net.inet.rss.hashalgo: 2
hw.bxe.udp_rss: 0
hw.ix.enable_rss: 1

root@OPNsense:~ # netstat -Q
Configuration:
Setting                        Current        Limit
Thread count                         4            4
Default queue limit                256        10240
Dispatch policy                 direct          n/a
Threads bound to CPUs          enabled          n/a

Protocols:
Name   Proto QLimit Policy Dispatch Flags
ip         1   1000    cpu   hybrid   C--
igmp       2    256 source  default   ---
rtsock     3    256 source  default   ---
arp        4    256 source  default   ---
ether      5    256    cpu   direct   C--
ip6        6    256   flow  default   ---
ip_direct     9    256    cpu   hybrid   C--
ip6_direct    10    256    cpu   hybrid   C--

Workstreams:
WSID CPU   Name     Len WMark   Disp'd  HDisp'd   QDrops   Queued  Handled
   0   0   ip         0     4        0      664        0     6779     7443
   0   0   igmp       0     0        0        0        0        0        0
   0   0   rtsock     0     0        0        0        0        0        0
   0   0   arp        0     0      415        0        0        0      415
   0   0   ether      0     0     2429        0        0        0     2429
   0   0   ip6        0     1       39        0        0        6       45
   0   0   ip_direct     0     0        0        0        0        0        0
   0   0   ip6_direct     0     0        0        0        0        0        0
   1   1   ip         0     6        0      688        0     6492     7180
   1   1   igmp       0     0        0        0        0        0        0
   1   1   rtsock     0     7        0        0        0      338      338
   1   1   arp        0     0      188        0        0        0      188
   1   1   ether      0     0     1955        0        0        0     1955
   1   1   ip6        0     2      114        0        0       31      145
   1   1   ip_direct     0     0        0        0        0        0        0
   1   1   ip6_direct     0     0        0        0        0        0        0
   2   2   ip         0     5        0     1341        0     2715     4056
   2   2   igmp       0     0        0        0        0        0        0
   2   2   rtsock     0     0        0        0        0        0        0
   2   2   arp        0     0       73        0        0        0       73
   2   2   ether      0     0     4118        0        0        0     4118
   2   2   ip6        0     0      782        0        0        0      782
   2   2   ip_direct     0     0        0        0        0        0        0
   2   2   ip6_direct     0     0        0        0        0        0        0
   3   3   ip         0    16        0      353        0     4932     5285
   3   3   igmp       0     0        0        0        0        0        0
   3   3   rtsock     0     0        0        0        0        0        0
   3   3   arp        0     0        0        0        0        0        0
   3   3   ether      0     0      568        0        0        0      568
   3   3   ip6        0     1       26        0        0        1       27
   3   3   ip_direct     0     0        0        0        0        0        0
   3   3   ip6_direct     0     0        0        0        0        0        0

I also have an ix based card and it seems you're also having the same issue I'm having in regards to ip6 not having RSS enabled.  Not sure why this would be but it was enabled for me with the previous kernel version.

One thing I noticed between the two kernels is that ip6 went from hybrid to direct.  Not sure why ip6 wouldn't have RSS enabled.  Do we need to have a tunable set for this as well?

Even though I already think I know the answer to this, I feel I need to ask.  I'm assuming that if we upgraded to this but didn't modify any firewall rules, we're not affected by this bug?

Will there be an updated test kernel for 21.7.2?  I know it was just released today but figured I'd ask as I'm interested in testing this.

I would love to see this as well.

EDIT: May have found them here..  https://github.com/opnsense/core/blob/21.7.1/src/etc/config.xml.sample

I can confirm this.  I haven't had much time myself to look at logs.  Have you been able to see if any of the system or suricata logs say anything?

Thanks franco.  Appreciate the help and response!

I apologize, the entire day was busy.  I think we are good as there haven't been any issues here on my end.  Did the latest push to the production channel of 21.1 include the fix?

Thanks again!

@franco, assuming you just want me to patch my system and report back that it doesn't break anything on my end even though I'm not having the same issue as mhofer?

If so, I'll patch it and reboot after work.

UPDATE: I had some time on a break and patched the system.  Patched the system and rebooted.  All appears to be working but I'd like to see if I notice anything overnight.  I'll be sure to update this post tomorrow.

Also once this is added in, I'm assuming this will be in the development channel and not in the 21.1 production one until Thursday?  Didn't know if you wanted me to test something in the development channel after it's merged just to be sure there are no issues when the production release is released.

Decided to bite the bullet and just do it as it could be reversed.  Disabled my HE tunnel and plugged in the RD settings
  Fired right up and I'm up and running.  I'll reboot tonight to test that out.  Thank you both again and if I can help testing anything, else I would love to.  So far this version of 21.1 has been rock solid.

I'm not sure I can help with the 64 tracking issue but what I can help with is testing this against my instance I have running on 21.1 production channel.  Would I be alright implementing these two patches together on that?   Assuming I need both from what it looks like?

Trying to offer up another test system since my provider uses RD (I hate it and I wish they would change).

Thank you both for the help in solving this!  I have been using HE for awhile to get around this pain point and would like to switch back.