Realtek's NIC driver pass parameters?

JimBob Indiana

It is enough that the Realtek driver works and recognizes the Realtek 2.5gb card. More than enough in fact. Thanks for the work to figure out how to do so.

With other NIC's we can pass parameters, usually minor performance tweaks but not always, to those NIC's.

Example:

"dev.em.0.rx_int_delay: 250"

My assumption is passing parameters works but only with internal or included NIC drivers. Since the Realtek driver is third party, external if you will, parameter options are not applicable. There's a difference between PFSense passing variables on to a PFSense driver vs. PFSense passing variables to a stand alone driver.

But there are some parameters that work with Realtek's own driver.

Examples:

hw.re.max_rx_mbuf_sz="2048"

hw.re.msi_disable=1

Also the options in Advanced Network impact Realtek's own driver performance. Something has to be getting passed from PFSense to the Realtek driver.

Are there and if so what are the available tweaks which can be passed to the Realtek NIC via loader.local.conf, etc. when using Realtek's driver?

Dobby_

All is given by the used hardware and on top of this what the driver is allowing to "tune". So this can be different from NIC
to NIC and driver to driver, or let us say varying.

Are there and if so what are the available tweaks which
can be passed to the Realtek NIC via loader.local.conf,
etc. when using Realtek's driver?

In normal you will be able to see this (what is able to tune)
in the manual of pfSense and/or FreeBSD.

pfSense hardware tune
FreeBSD Tunings

Please accept that in some cases more then one tuning is playing nice together with others and this will be then bringing the wished effect to that system, I mean not only
one thing is set up and is working fine for you.

stephenw10

The Realtek driver will still accept loader variables and sysctls. Those may differ from the FreeBSD native re(4) driver.
You can see the available sysctls:

[23.01-RC][admin@apu.stevew.lan]/root: sysctl dev.re.0
dev.re.0.%parent: pci1
dev.re.0.%pnpinfo: vendor=0x10ec device=0x8168 subvendor=0x10ec subdevice=0x0123 class=0x020000
dev.re.0.%location: slot=0 function=0 dbsf=pci0:1:0:0
dev.re.0.%driver: re
dev.re.0.%desc: Realtek PCIe GbE Family Controller
[23.01-RC][admin@apu.stevew.lan]/root: sysctl hw.re
hw.re.max_rx_mbuf_sz: 9216
hw.re.s0_magic_packet: 0
hw.re.s5wol: 0
hw.re.phy_mdix_mode: 2
hw.re.phy_power_saving: 1
hw.re.eee_enable: 0
hw.re.prefer_iomap: 0
hw.re.msix_disable: 0
hw.re.msi_disable: 1

Limited compared to Intel NICs.

JimBob Indiana

@stephenw10

Thanks.

With the other makes of NIC's you have to do a number, igc.0, igc.1, etc.

These set the available parameters for all Realtek devices or do you still need to target devices with the number? re.0, re.1, etc.

stephenw10

hw.re is set for all re devices and those are often loader variables that are read-only after boot.

dev.re.X is per NIC and can be tunable after boot or might be stats values. Though it doesn't look like they are in this case.

Steve

JimBob Indiana

@stephenw10

“Doesn’t look like they are in this case”

That’s what it looks like to me as well. Which again is fine. Just curious. With the built in 1gb Realtek and using the included Realtek driver I could pass settings to the individual card using the re.x in loader.conf.local.

Nothing I find on setting parameters using Realtek’s driver appear tied to a specific NIC. Global only.

I ran the same sysctl commands. The dev.re list both ports so re.0 and re.1 but in the hw.re information is global as yours.

The information I can find is not current either. It’s in threads of people trying to make the Realtek cards work, compiling their own driver, etc., before PFSense included the Realtek driver.

The results of the hw.re is the current settings?

I found this regarding 1.98.

https://github.com/alexdupre/rtl_bsd_drv/blob/v1.98/if_rereg.h

stephenw10

The results of the hw.re are what are created by default. That doesn't mean the driver can't accept more.
That file is a list of the chip registers not values exported as sysctls.

You can they were switched to read only in the 1.98 version of the kmod pkg though:
https://github.com/alexdupre/rtl_bsd_drv/commit/d0fabed97a0cb25d57fa2cbf0719caf742129aba

JimBob Indiana

@stephenw10

Found this as well.

https://manpages.ubuntu.com/manpages/focal/en/man4/if_re.4freebsd.html

“ switched to read only in the 1.98”

So that means manually entered parameters be it System Advance Tunables or Loader file won’t matter?

stephenw10

Only for hw.re. Which are usually read-only loader values in other divers. Probably why they were changed to that here.

JimBob Indiana

@stephenw10

I’ve gotten a handful of commands to take. Like the MSI/MSI-x ones. Quite a few of them either do nothing or I can’t or don’t know how to check. Are you SURE you increased the Receive Buffer size?

In digging around I found IFConfig pushes the tweaked parameters to the card.

It works to turn off the receiver buffer, etc., by sending this via IFConfig. Ifconfig re.x -RXCSUM or -TXCSUM.

Barely any additional information regarding tweaks though. As you noted with the Intel cards there’s a lot of them.

stephenw10

I've not tried to set any values. The default values work well for me on the APU.