Re: Network starvation question
Hi Yuri, If I understand your situation correctly, your application A is using UDP but application B is using TCP and the max outbound bandwidth is < 4MBps. If A can send at 3.5 Mbps and B can send at 0.5 Mbps, why B is suffering more in throughput when the outbound limit is < 4Mbps? There are many factors I think in my experience that can contribute to this. But maybe we prefer a solution rather than the root cause of the difference. If you can tune A to use less bandwidth and let B to use the full 0.5 Mbps, the problem may be solved. (for example, iperf default in UDP is ~1Mbps but can be tuned to send at max bandwidth, so vice versa) Then, back to the possible contribution factors of TCP suffering from a UDP traffic competition : 1. UDP traffic rate can be considered constant so it does not yield 2. TCP congestion control may be encountered 3. application's responsiveness may be different Best Regards, Cheng Cui On Fri, Nov 3, 2023 at 12:42 AM Yuri wrote: > Hi, > > > I've encountered the situation when the application A was using 100% of > the outbound bandwidth which is approximately 3.5 MBps of UDP traffic. > > Then the application B (the RDP TCP connection) attempted to use a much > lower outbound speed, probably < 0.5 MBps, and it got starved. > > Application B (RDP) was super slow as long as the application A kept > running. It was almost impossible to use the RDP connection. > > > My question is: shouldn't the system allow less intense streams to also > run at a decent speed? > > > Let's say that the outbound bandwidth threshold of the connection is 3.5 > MBps. > > The application A can send 3.5 MBps (or more). > > The application B can send up to 0.5 MBps. > > Obviously, they can't send 4.0 MBps in total, and their speeds should be > tuned down. > > If both of the applications would be tuned down proportionately, this > could be done using the 3.5/4.0 ratio, which would be 0.875. > > So why then does the slower connection get slowed down so much? > > It was obviously slowed down many times, not just by 13%. > > > FreeBSD 13.2 > > > Thanks, > > Yuri > > > >
tcp and udp traffic over IPv6 does not work from the latest e1000 git change 918c25677d
-n 2K Client connecting to fd00::3, TCP port 5001 TCP window size: 32.3 KByte (default) [ 1] local fd00::2 port 27164 connected with fd00::3 port 5001 [ ID] Interval Transfer Bandwidth [ 1] 0.00-0.02 sec 2.00 KBytes 858 Kbits/sec cc@r1:~ % iperf -VsB fd00::3 Server listening on TCP port 5001 TCP window size: 64.0 KByte (default) [ 1] local fd00::3 port 5001 connected with fd00::2 port 27164 [ ID] Interval Transfer Bandwidth [ 1] 0.00-0.00 sec 2.00 KBytes 0.000 bits/sec UDP traffic also works: root@s1:~ # iperf -Vc fd00::3 --udp -n 2K Client connecting to fd00::3, UDP port 5001 Sending 1450 byte datagrams, IPG target: 11062.62 us (kalman adjust) UDP buffer size: 9.00 KByte (default) [ 1] local fd00::2 port 64612 connected with fd00::3 port 5001 [ ID] Interval Transfer Bandwidth [ 1] 0.00-0.01 sec 3.42 KBytes 2.36 Mbits/sec [ 1] Sent 4 datagrams [ 1] Server Report: [ ID] Interval Transfer BandwidthJitter Lost/Total Datagrams [ 1] 0.00-0.01 sec 3.42 KBytes 2.38 Mbits/sec 0.010 ms 0/3 (0%) cc@r1:~ % iperf -VsB fd00::3 --udp Server listening on UDP port 5001 UDP buffer size: 41.1 KByte (default) [ 1] local fd00::3 port 5001 connected with fd00::2 port 64612 [ ID] Interval Transfer BandwidthJitter Lost/Total Datagrams [ 1] 0.00-0.01 sec 3.42 KBytes 2.38 Mbits/sec 0.011 ms 0/3 (0%) Best Regards, Cheng Cui
Re: CFT: lem(4), em(4) e1000 Ethernet TSO testing
I didn't see your post covering 82541 or 82546 chips. Does this new em(4) change support TSO on these chips? If yes, I would be happy to test it on them. root@s1:~ # dmesg | grep 8254 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 em0: port 0xdcc0-0xdcff mem 0xdfae-0xdfaf irq 64 at device 7.0 on pci6 em1: port 0xccc0-0xccff mem 0xdf8e-0xdf8f irq 65 at device 8.0 on pci7 em2: port 0xbcc0-0xbcff mem 0xdf5e-0xdf5f irq 106 at device 4.0 on pci9 em3: port 0xbc80-0xbcbf mem 0xdf5c-0xdf5d irq 107 at device 4.1 on pci9 em4: port 0xacc0-0xacff mem 0xdf3e-0xdf3f irq 101 at device 3.0 on pci10 em5: port 0xac80-0xacbf mem 0xdf3c-0xdf3d irq 102 at device 3.1 on pci10 Best Regards, Cheng Cui On Tue, Jul 25, 2023 at 10:38 PM Kevin Bowling wrote: > Hi, > > I have been working through various bugs and have come to a point > where TSO is working on systems I have available for testing. > > This results in higher throughput on resource constrained systems, and > less CPU/power usage on unconstrained systems. > > As of this mail, you will need to manually apply > https://reviews.freebsd.org/D41170 on top of main to use TSO6 on > em(4). > > I plan to enable TSO by default for lem(4) and em(4) during the > FreeBSD 14 release cycle, so I would appreciate testing to address any > remaining issues. Below, a list of chipsets that will be exempt due > to known issues. > > lem(4) exclusions: > * <82544 (although it does seem ok to manually enable for emulations > in qemu, virtualbox, etc) > * 82547 > > em(4) exclusions.. These chips have a stability workaround for high > throughput with rapid link-flap applied that results in the TSO engine > not being able to run at line speed. Thus, TSO would not be enabled > by default here: > * Intel(R) I219-LM and I219-V > * Intel(R) I219-LM and I219-V (2) > * Intel(R) I219-LM and I219-V (3) > * Intel(R) I219-LM and I219-V (4) > * Intel(R) I219-LM and I219-V (5) > > Regards, > Kevin Bowling > >
Re: -current dropping ssh connections
> > There don't seem to be any error messages on the console at all, the > client > session simply reports > client_loop: send disconnect: Broken pipe > Have you tried SSH keepalive? https://stackoverflow.com/questions/25084288/keep-ssh-session-alive Best Regards, Cheng Cui On Wed, Jun 21, 2023 at 1:24 PM bob prohaska wrote: > I've got a Pi4 running -current that seems to selectively drop ssh > connections. > > Connections running a shell seem to stay up, but a session running tip to a > usb-serial adapter (FTDI TTL232R-3V3) seems go away within a few hours. > There don't seem to be any error messages on the console at all, the > client > session simply reports > client_loop: send disconnect: Broken pipe > > Searches through /var/log/sshd_debug.log find many transactions between > the ssh client and the -current target host, but none seem to be error > messages; all are either connection reports or disconnects by user. > > This sort of behavior has been intermittent with aarch64 among both > the Pi4 and a pair of Pi3s for some time, but now only the Pi4 is > dropping connections. > > I've tried searching /var/log/sshd_debug.log for the keywords tip, > ucom, the IP address of the NAT client used to connect and cuaU0. > Are there other things worth looking for? > > Right now I'm using in /etc/rc.conf the line > sshd_flags="-E /var/log/sshd_debug.log" > which is already quite verbose. Is there a better > option that emphasizes errors over normal traffic? > > Thanks for reading, > > bob prohaska > > > >
Re: how to increase the vnet speed?
>From TCP's point of view, your iperf result shows "Retr" as retransmissions. Well, that tells packet drops or something else which makes TCP's congestion control into playing throttling the throughput to a certain degree. Try a different TCP congestion control. If the default is CUBIC, try to use NewReno. I don't know your FreeBSD version. So if it is FreeBSD14-current, I would like to see the difference as there is improvement discussion on CUBIC. cc@fbsd ~$ sysctl net.inet.tcp.cc net.inet.tcp.cc.newreno.beta_ecn: 80 net.inet.tcp.cc.newreno.beta: 50 net.inet.tcp.cc.abe_frlossreduce: 0 net.inet.tcp.cc.abe: 0 net.inet.tcp.cc.available: newreno net.inet.tcp.cc.algorithm: newreno cc@fbsd ~$ sysctl net.inet.tcp.cc.available net.inet.tcp.cc.available: newreno cc@fbsd ~$ sudo kldload cc_cubic<< load TCP congestion control module cc_cubic cc@fbsd ~$ sysctl net.inet.tcp.cc.available net.inet.tcp.cc.available: newreno, cubic cc@fbsd ~$ sudo sysctl net.inet.tcp.cc.algorithm=cubic net.inet.tcp.cc.algorithm: newreno -> cubic cc@fbsd ~$ sudo sysctl net.inet.tcp.cc.algorithm net.inet.tcp.cc.algorithm: cubic cc@fbsd ~$ uname -a FreeBSD fbsd.cc.home 13.1-RELEASE FreeBSD 13.1-RELEASE releng/13.1-n250148-fc952ac2212 GENERIC amd64 cc@fbsd ~$ Best Regards, Cheng Cui On Wed, May 24, 2023 at 2:19 AM Benoit Chesneau wrote: > Sorry, I thought I posted it but it's a bridge: > > ``` > vlan200: flags=8943 metric > 0 mtu 9000 > > options=1c280401 > ether 9c:dc:71:4c:84:f0 > groups: vlan > vlan: 200 vlanproto: 802.1q vlanpcp: 0 parent interface: mce0 > media: Ethernet 25GBase-SR > status: active > nd6 options=29 > vlan200bridge: flags=8843 metric 0 > mtu 9000 > ether 58:9c:fc:10:ff:95 > id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 > maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 > root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 > member: e0a_bastille0 flags=143 > ifmaxaddr 0 port 10 priority 128 path cost 2000 > member: vlan200 flags=143 > ifmaxaddr 0 port 8 priority 128 path cost 800 > groups: bridge > nd6 options=9 > e0a_bastille0: flags=8963 > metric 0 mtu 9000 > description: vnet host interface for Bastille jail testing > options=8 > ether 02:20:98:4c:84:f0 > hwaddr 02:68:8a:24:67:0a > groups: epair > media: Ethernet 10Gbase-T (10Gbase-T ) > status: active > nd6 options=29 > ``` > > After relaunching the machine and removed filtering: > > ``` > net.link.bridge.pfil_bridge=0 > net.link.bridge.pfil_onlyip=0 > net.link.bridge.pfil_member=0 > ``` > > I get better results. Still not dull speed but since it's in a bridge > seems normal. Unsure what was the issue... > > ``` > [ ID] Interval Transfer Bitrate Retr Cwnd > [ 5] 0.00-1.01 sec 1.75 GBytes 14.8 Gbits/sec 74936 KBytes > [ 5] 1.01-2.00 sec 1.31 GBytes 11.3 Gbits/sec 27 1.76 MBytes > [ 5] 2.00-3.00 sec 2.12 GBytes 18.2 Gbits/sec 34 1.74 MBytes > [ 5] 3.00-4.00 sec 2.08 GBytes 17.9 Gbits/sec 85 1.75 MBytes > [ 5] 4.00-5.00 sec 2.11 GBytes 18.2 Gbits/sec 37 1.75 MBytes > [ 5] 5.00-6.00 sec 2.09 GBytes 18.0 Gbits/sec 60 1.75 MBytes > [ 5] 6.00-7.00 sec 2.11 GBytes 18.2 Gbits/sec 10 1.50 MBytes > [ 5] 7.00-8.00 sec 1.51 GBytes 13.0 Gbits/sec 27 1.75 MBytes > [ 5] 8.00-9.00 sec 1.48 GBytes 12.7 Gbits/sec 75 1.50 MBytes > [ 5] 9.00-10.00 sec 2.09 GBytes 17.9 Gbits/sec 52 1.58 MBytes > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Retr > [ 5] 0.00-10.00 sec 18.7 GBytes 16.0 Gbits/sec 481 > sender > [ 5] 0.00-10.00 sec 18.7 GBytes 16.0 Gbits/sec > receiver > ``` > > > > Benoît > > > --- Original Message --- > On Tuesday, May 23rd, 2023 at 23:15, Marko Zec wrote: > > > > On Tue, 23 May 2023 19:58:07 + > > Benoit Chesneau beno...@enki-multimedia.eu wrote: > > > > > Hi all, > > > > > > I've created a jail using bastille and setup network. The mainin > > > terface is a 25Gbps nic and between hosts I get 24.6 Gbits/sec : > > > > > > [...] > > > > > But between one host and the jail I only get 3.96 Gbits/sec > > > > > > [...] > > > > > Is there a way to increase the performance of the of the jail? The > > > nice is a mellannox ConnectX-4 Lx, mce(4) . > > > > > > Modern NICs offload a lot of the protocol stack processing (checksum, > > segmentation, and / or reassembly) from the CPU to dedicated silicon, > > whereas inter-vnet traffic needs to be handled completely in software, > > that's where the difference comes from. > > > > Perhaps we could gain some speed by abusing mbuf flags to skip RXCSUM > > for epair traffic, maybe even skip and fake TXCSUM... > > > > Marko > >
Re: missing hw.em.msix support in FreeBSD 14.0-CURRENT?
On Mon, May 8, 2023 at 9:50 AM Yuri wrote: > Cheng Cui wrote: > > A followup question: Shouldn't the man page for em(4) be updated > > accordingly, as the sysctls are different now? > > > > https://man.freebsd.org/cgi/man.cgi?em(4) > > <https://man.freebsd.org/cgi/man.cgi?em(4)> > > https://reviews.freebsd.org/D3 > > Thanks for taking care of this. It looks good to me. :) cc
Re: missing hw.em.msix support in FreeBSD 14.0-CURRENT?
Found the RSS support, only if the hardware is ">= e1000_82571" from the if_em.c. if (hw->mac.type >= em_mac_min)// #define em_mac_min e1000_82571 > ... > scctx->isc_txrx = _txrx; > ... > > Best Regards, Cheng Cui On Sun, May 7, 2023 at 7:28 PM Cheng Cui wrote: > Hi Yuri, > > Thanks for the update. I am using an Emulab testbed node under the same > type of hardware. Below are the new outputs. > It is supposed to have multiple tx/rx queues under msix. Why are there > only rxq0/txq0? Is it because the CPU has only one core? How can I check if > RSS is supported? > > root@s1:~ # sysctl -d dev.em.0.iflib.disable_msix > dev.em.0.iflib.disable_msix: disable MSI-X (default 0) > root@s1:~ # sysctl dev.em.0.iflib.disable_msix > dev.em.0.iflib.disable_msix: 0 > root@s1:~ # sysctl dev.em.0.iflib > dev.em.0.iflib.rxq0.rxq_fl0.buf_size: 2048 > dev.em.0.iflib.rxq0.rxq_fl0.credits: 1023 > dev.em.0.iflib.rxq0.rxq_fl0.cidx: 959 > dev.em.0.iflib.rxq0.rxq_fl0.pidx: 958 > dev.em.0.iflib.rxq0.cpu: 1 > dev.em.0.iflib.txq0.r_abdications: 0 > dev.em.0.iflib.txq0.r_restarts: 0 > dev.em.0.iflib.txq0.r_stalls: 0 > dev.em.0.iflib.txq0.r_starts: 110443 > dev.em.0.iflib.txq0.r_drops: 0 > dev.em.0.iflib.txq0.r_enqueues: 110444 > dev.em.0.iflib.txq0.ring_state: pidx_head: 1903 pidx_tail: 1903 cidx: 1903 > state: IDLE > dev.em.0.iflib.txq0.txq_cleaned: 115208 > dev.em.0.iflib.txq0.txq_processed: 115251 > dev.em.0.iflib.txq0.txq_in_use: 42 > dev.em.0.iflib.txq0.txq_cidx_processed: 565 > dev.em.0.iflib.txq0.txq_cidx: 525 > dev.em.0.iflib.txq0.txq_pidx: 568 > dev.em.0.iflib.txq0.no_tx_dma_setup: 0 > dev.em.0.iflib.txq0.txd_encap_efbig: 0 > dev.em.0.iflib.txq0.tx_map_failed: 0 > dev.em.0.iflib.txq0.no_desc_avail: 0 > dev.em.0.iflib.txq0.mbuf_defrag_failed: 0 > dev.em.0.iflib.txq0.m_pullups: 0 > dev.em.0.iflib.txq0.mbuf_defrag: 0 > dev.em.0.iflib.txq0.cpu: 0 > dev.em.0.iflib.override_nrxds: 0 > dev.em.0.iflib.override_ntxds: 0 > dev.em.0.iflib.use_logical_cores: 0 > dev.em.0.iflib.separate_txrx: 0 > dev.em.0.iflib.core_offset: 0 > dev.em.0.iflib.tx_abdicate: 0 > dev.em.0.iflib.rx_budget: 0 > dev.em.0.iflib.disable_msix: 0 > dev.em.0.iflib.override_qs_enable: 0 > dev.em.0.iflib.override_nrxqs: 0 > dev.em.0.iflib.override_ntxqs: 0 > dev.em.0.iflib.driver_version: 7.7.8-fbsd > root@s1:~ # > > > Best Regards, > Cheng Cui > > > On Sun, May 7, 2023 at 4:18 PM Yuri wrote: > >> Cheng Cui wrote: >> > Hello, >> > >> > I am using this em(4) driver for some tests. According to the man page >> > below, there should be a "hw.em.msix" sysctl to enable/disable MSI-X >> > style interrupts. But why is it missing in my system below? >> > https://man.freebsd.org/cgi/man.cgi?em(4) >> > <https://man.freebsd.org/cgi/man.cgi?em(4)> >> > >> > root@s1:~ # dmesg | egrep "8254" >> > Timecounter "i8254" frequency 1193182 Hz quality 0 >> > Event timer "i8254" frequency 1193182 Hz quality 100 >> > em0: port 0xdcc0-0xdcff mem >> > 0xdfae-0xdfaf irq 64 at device 7.0 on pci6 >> > em1: port 0xccc0-0xccff mem >> > 0xdf8e-0xdf8f irq 65 at device 8.0 on pci7 >> > em2: port 0xbcc0-0xbcff >> > mem 0xdf5e-0xdf5f irq 106 at device 4.0 on pci9 >> > em3: port 0xbc80-0xbcbf >> > mem 0xdf5c-0xdf5d irq 107 at device 4.1 on pci9 >> > em4: port 0xacc0-0xacff >> > mem 0xdf3e-0xdf3f irq 101 at device 3.0 on pci10 >> > em5: port 0xac80-0xacbf >> > mem 0xdf3c-0xdf3d irq 102 at device 3.1 on pci10 >> > >> > root@s1:~ # ifconfig em5 >> > em5: flags=8843 metric 0 mtu >> 1500 >> > >> options=481009b >> > ether 00:04:23:b7:1e:1d >> > inet 10.1.1.2 netmask 0xff00 broadcast 10.1.1.255 >> > media: Ethernet 1000baseT >> > status: active >> > nd6 options=29 >> > >> > root@s1:~ # sysctl hw.em >> > hw.em.max_interrupt_rate: 8000 >> > hw.em.eee_setting: 1 >> > hw.em.rx_process_limit: 100 >> > hw.em.sbp: 0 >> > hw.em.smart_pwr_down: 0 >> > hw.em.rx_abs_int_delay: 66 >> > hw.em.tx_abs_int_delay: 66 >> > hw.em.rx_int_delay: 0 >> > hw.em.tx_int_delay: 66 >> > hw.em.disable_crc_stripping: 0 >> > root@s1:~ # >> >> As if_em was converted to iflib, I guess the related sysctl would now be >> dev.em.0.iflib.disable_msix (I could be wrong, don't have h/w to check). >> >
Re: missing hw.em.msix support in FreeBSD 14.0-CURRENT?
Hi Yuri, Thanks for the update. I am using an Emulab testbed node under the same type of hardware. Below are the new outputs. It is supposed to have multiple tx/rx queues under msix. Why are there only rxq0/txq0? Is it because the CPU has only one core? How can I check if RSS is supported? root@s1:~ # sysctl -d dev.em.0.iflib.disable_msix dev.em.0.iflib.disable_msix: disable MSI-X (default 0) root@s1:~ # sysctl dev.em.0.iflib.disable_msix dev.em.0.iflib.disable_msix: 0 root@s1:~ # sysctl dev.em.0.iflib dev.em.0.iflib.rxq0.rxq_fl0.buf_size: 2048 dev.em.0.iflib.rxq0.rxq_fl0.credits: 1023 dev.em.0.iflib.rxq0.rxq_fl0.cidx: 959 dev.em.0.iflib.rxq0.rxq_fl0.pidx: 958 dev.em.0.iflib.rxq0.cpu: 1 dev.em.0.iflib.txq0.r_abdications: 0 dev.em.0.iflib.txq0.r_restarts: 0 dev.em.0.iflib.txq0.r_stalls: 0 dev.em.0.iflib.txq0.r_starts: 110443 dev.em.0.iflib.txq0.r_drops: 0 dev.em.0.iflib.txq0.r_enqueues: 110444 dev.em.0.iflib.txq0.ring_state: pidx_head: 1903 pidx_tail: 1903 cidx: 1903 state: IDLE dev.em.0.iflib.txq0.txq_cleaned: 115208 dev.em.0.iflib.txq0.txq_processed: 115251 dev.em.0.iflib.txq0.txq_in_use: 42 dev.em.0.iflib.txq0.txq_cidx_processed: 565 dev.em.0.iflib.txq0.txq_cidx: 525 dev.em.0.iflib.txq0.txq_pidx: 568 dev.em.0.iflib.txq0.no_tx_dma_setup: 0 dev.em.0.iflib.txq0.txd_encap_efbig: 0 dev.em.0.iflib.txq0.tx_map_failed: 0 dev.em.0.iflib.txq0.no_desc_avail: 0 dev.em.0.iflib.txq0.mbuf_defrag_failed: 0 dev.em.0.iflib.txq0.m_pullups: 0 dev.em.0.iflib.txq0.mbuf_defrag: 0 dev.em.0.iflib.txq0.cpu: 0 dev.em.0.iflib.override_nrxds: 0 dev.em.0.iflib.override_ntxds: 0 dev.em.0.iflib.use_logical_cores: 0 dev.em.0.iflib.separate_txrx: 0 dev.em.0.iflib.core_offset: 0 dev.em.0.iflib.tx_abdicate: 0 dev.em.0.iflib.rx_budget: 0 dev.em.0.iflib.disable_msix: 0 dev.em.0.iflib.override_qs_enable: 0 dev.em.0.iflib.override_nrxqs: 0 dev.em.0.iflib.override_ntxqs: 0 dev.em.0.iflib.driver_version: 7.7.8-fbsd root@s1:~ # Best Regards, Cheng Cui On Sun, May 7, 2023 at 4:18 PM Yuri wrote: > Cheng Cui wrote: > > Hello, > > > > I am using this em(4) driver for some tests. According to the man page > > below, there should be a "hw.em.msix" sysctl to enable/disable MSI-X > > style interrupts. But why is it missing in my system below? > > https://man.freebsd.org/cgi/man.cgi?em(4) > > <https://man.freebsd.org/cgi/man.cgi?em(4)> > > > > root@s1:~ # dmesg | egrep "8254" > > Timecounter "i8254" frequency 1193182 Hz quality 0 > > Event timer "i8254" frequency 1193182 Hz quality 100 > > em0: port 0xdcc0-0xdcff mem > > 0xdfae-0xdfaf irq 64 at device 7.0 on pci6 > > em1: port 0xccc0-0xccff mem > > 0xdf8e-0xdf8f irq 65 at device 8.0 on pci7 > > em2: port 0xbcc0-0xbcff > > mem 0xdf5e-0xdf5f irq 106 at device 4.0 on pci9 > > em3: port 0xbc80-0xbcbf > > mem 0xdf5c-0xdf5d irq 107 at device 4.1 on pci9 > > em4: port 0xacc0-0xacff > > mem 0xdf3e-0xdf3f irq 101 at device 3.0 on pci10 > > em5: port 0xac80-0xacbf > > mem 0xdf3c-0xdf3d irq 102 at device 3.1 on pci10 > > > > root@s1:~ # ifconfig em5 > > em5: flags=8843 metric 0 mtu 1500 > > > options=481009b > > ether 00:04:23:b7:1e:1d > > inet 10.1.1.2 netmask 0xff00 broadcast 10.1.1.255 > > media: Ethernet 1000baseT > > status: active > > nd6 options=29 > > > > root@s1:~ # sysctl hw.em > > hw.em.max_interrupt_rate: 8000 > > hw.em.eee_setting: 1 > > hw.em.rx_process_limit: 100 > > hw.em.sbp: 0 > > hw.em.smart_pwr_down: 0 > > hw.em.rx_abs_int_delay: 66 > > hw.em.tx_abs_int_delay: 66 > > hw.em.rx_int_delay: 0 > > hw.em.tx_int_delay: 66 > > hw.em.disable_crc_stripping: 0 > > root@s1:~ # > > As if_em was converted to iflib, I guess the related sysctl would now be > dev.em.0.iflib.disable_msix (I could be wrong, don't have h/w to check). >
missing hw.em.msix support in FreeBSD 14.0-CURRENT?
Hello, I am using this em(4) driver for some tests. According to the man page below, there should be a "hw.em.msix" sysctl to enable/disable MSI-X style interrupts. But why is it missing in my system below? https://man.freebsd.org/cgi/man.cgi?em(4) root@s1:~ # dmesg | egrep "8254" Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 em0: port 0xdcc0-0xdcff mem 0xdfae-0xdfaf irq 64 at device 7.0 on pci6 em1: port 0xccc0-0xccff mem 0xdf8e-0xdf8f irq 65 at device 8.0 on pci7 em2: port 0xbcc0-0xbcff mem 0xdf5e-0xdf5f irq 106 at device 4.0 on pci9 em3: port 0xbc80-0xbcbf mem 0xdf5c-0xdf5d irq 107 at device 4.1 on pci9 em4: port 0xacc0-0xacff mem 0xdf3e-0xdf3f irq 101 at device 3.0 on pci10 em5: port 0xac80-0xacbf mem 0xdf3c-0xdf3d irq 102 at device 3.1 on pci10 root@s1:~ # ifconfig em5 em5: flags=8843 metric 0 mtu 1500 options=481009b ether 00:04:23:b7:1e:1d inet 10.1.1.2 netmask 0xff00 broadcast 10.1.1.255 media: Ethernet 1000baseT status: active nd6 options=29 root@s1:~ # sysctl hw.em hw.em.max_interrupt_rate: 8000 hw.em.eee_setting: 1 hw.em.rx_process_limit: 100 hw.em.sbp: 0 hw.em.smart_pwr_down: 0 hw.em.rx_abs_int_delay: 66 hw.em.tx_abs_int_delay: 66 hw.em.rx_int_delay: 0 hw.em.tx_int_delay: 66 hw.em.disable_crc_stripping: 0 root@s1:~ # Best Regards, Cheng Cui
