netpfil tests: make dummynet tests more robust
These tests try to verify that packet prioritisation works as expected. This is
inherently a statistical process, and is difficuly to measure automatically.
Run the tests more times and accept more failures.
Sponsored by: Rubicon Communications, LLC ("Netgate")
igc: sysctl for TCP flag handling during TSO
Add tso_tcp_flags_mask_first_segment, tso_tcp_flags_mask_middle_segment,
and tso_tcp_flags_mask_last_segment sysctl-variables to control the
handling of TCP flags during TSO.
This allows to change the masks appropriate for classical ECN and to
configure appropriate masks for accurate ECN.
Sponsored by: Netflix
(cherry picked from commit ab540d44ba3201ff8313b90ba0096004603b2e34)
e1000: sysctl for TCP flag handling during TSO
Add tso_tcp_flags_mask_first_segment, tso_tcp_flags_mask_middle_segment,
and tso_tcp_flags_mask_last_segment sysctl-variables to control the
handling of TCP flags during TSO.
This allows to change the masks appropriate for classical ECN and to
configure appropriate masks for accurate ECN.
Reviewed by: rrs
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D44259
(cherry picked from commit 90853dfac851afa9e8840f5a38383256d75458b6)
ixgbe: sysctl for TCP flag handling during TSO
Add tso_tcp_flags_mask_first_segment, tso_tcp_flags_mask_middle_segment,
and tso_tcp_flags_mask_last_segment sysctl-variables to control the
handling of TCP flags during TSO.
This allows to fix the masks appropriate for classical ECN and to
configure appropriate masks for accurate ECN.
Michael notes emperically 82599 has an unexpected middle mask:
Chip First Middle Last
82599 0xFF6 0xFF6 0xF7F
which should be fixed up to 0xF76 (RFC 3168) in a future commit.
Reviewed by: rrs, rscheff
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D44258
(cherry picked from commit eea2e089f8dadf850a30ed837edd7a386427a9ed)
igc: sysctl for TCP flag handling during TSO
Add tso_tcp_flags_mask_first_segment, tso_tcp_flags_mask_middle_segment,
and tso_tcp_flags_mask_last_segment sysctl-variables to control the
handling of TCP flags during TSO.
This allows to change the masks appropriate for classical ECN and to
configure appropriate masks for accurate ECN.
Sponsored by: Netflix
(cherry picked from commit ab540d44ba3201ff8313b90ba0096004603b2e34)
e1000: sysctl for TCP flag handling during TSO
Add tso_tcp_flags_mask_first_segment, tso_tcp_flags_mask_middle_segment,
and tso_tcp_flags_mask_last_segment sysctl-variables to control the
handling of TCP flags during TSO.
This allows to change the masks appropriate for classical ECN and to
configure appropriate masks for accurate ECN.
Reviewed by: rrs
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D44259
(cherry picked from commit 90853dfac851afa9e8840f5a38383256d75458b6)
ixgbe: sysctl for TCP flag handling during TSO
Add tso_tcp_flags_mask_first_segment, tso_tcp_flags_mask_middle_segment,
and tso_tcp_flags_mask_last_segment sysctl-variables to control the
handling of TCP flags during TSO.
This allows to fix the masks appropriate for classical ECN and to
configure appropriate masks for accurate ECN.
Michael notes emperically 82599 has an unexpected middle mask:
Chip First Middle Last
82599 0xFF6 0xFF6 0xF7F
which should be fixed up to 0xF76 (RFC 3168) in a future commit.
Reviewed by: rrs, rscheff
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D44258
(cherry picked from commit eea2e089f8dadf850a30ed837edd7a386427a9ed)
e1000: Try auto-negotiation for fixed 100 or 10 configuration
This is a retread of https://reviews.freebsd.org/D34449 which I think
will fix the issue for the remote side not supporting autoneg. We now
attempt an autoneg, and if that fails fall back to the current code
that forces the link speed/duplex.
The original intent of this patch is to inform the remote switch of
duplex settings when we (the client) are specifying a fixed 10 or 100
speed. Otherwise it may get the duplex setting wrong.
The tricky case is when the remote (switch) side is fixing its
speed AND duplex while disabling autoneg and we (client) need to do
the same, which still seems to be common enough at some ISPs.
Original commit message follows:
Currently if an e1000 interface is set to a fixed media configuration,
for gigabit, it will participate in auto-negotiation as required by
IEEE 802.3-2018 Clause 37. However, if set to fixed media configuration
[35 lines not shown]
FreeBSD: Reduce copy_file_range() source lock to shared
Linux locks copy_file_range() source as shared. FreeBSD was doing
it also, but then was changed to exclusive, partially because KPI
of that time was doing so, and partially seems out of caution.
Considering zfs_clone_range() uses range locks on both source and
destination, neither should require exclusive vnode locks. But one
step at a time, just sync it with Linux for now.
Reviewed-by: Alan Somers <asomers at gmail.com>
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Alexander Motin <mav at FreeBSD.org>
Sponsored by: iXsystems, Inc.
Closes #16789
Closes #16797
FreeBSD: Lock vnode in zfs_ioctl()
Previously vnode was not locked there, unlike Linux. It required
locking it in vn_flush_cached_data(), which recursed on the lock
if called from zfs_clone_range(), having the vnode locked.
Reviewed-by: Alan Somers <asomers at gmail.com>
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Alexander Motin <mav at FreeBSD.org>
Sponsored by: iXsystems, Inc.
Closes #16789
Closes #16796
find: Correct ls(1) equivalent command for -ls primary
After commit 3bfbb521fef5, -g stopped being a no-op. The -g hasn't
been required for equivalent output since 4.4BSD.
PR: 282901
Fixes: 3bfbb521 ls: Improve POSIX compatibility for -g and -n.
new-bus: Fix some shortcomings in disabling devices via hints
A device can be disabled via a hint after it is probed (but before it
is attached). The initial version of this marked the device disabled,
but left the device "alive" meaning that dev->driver and dev->desc
were untouched and still pointed into the driver that probed the
device. If that driver lives in a kernel module that is later
unloaded, device_detach() called from devclass_delete_driver() doesn't
do anything (the device's state is DS_ALIVE). In particular, it
doesn't call device_set_driver(dev, NULL) to disassociate the device
from the driver that is being unloaded.
There are several places where these stale pointers can be tripped
over. After kldunload, invoking the sysctl to fetch device info can
dereference dev->desc and dev->driver causing panics. Even without
kldunload, a system suspend request will call the device_suspend and
device_resume DEVMETHODs of the driver in question even though the
device is not attached which can cause some excitement.
[17 lines not shown]
Add new kern.vt.slow_down tunable.
On a laptop with no other console devices than the screen, things
scroll of the screen faster than eye or camera can capture it.
This tunable slows the console down and makes it update synchronously,
so console output continues when timers or interrupts do not.
Differential Revision: https://reviews.freebsd.org/D47710
mlx5: Fix handling of port_module_event
Remove the array of port module status and instead save module status
and module number.
At boot, for each PCI function driver get event from fw about module
status. The event contains module number and module status. Driver
stores module number and module status.. When user (ifconfig) ask for
modules information, for each pci function driver first queries fw to
get module number of current pci function, then driver compares the
module number to the module number it stored before and if it matches
and module status is "plugged and enabled" then driver queries fw for
the eprom information of that module number and return it to the
caller.
In fact fw could have concluded that required module number of the
current pci function, but fw is not implemented this way. current
design of PRM/FW is that MCIA register handling is only aware of
modules, not the pci function->module connections. FW is designed to
[8 lines not shown]
mlx5e tls: Ensure all allocated tags have a hw context associated
Ensure all allocated tags have a hardware context associated.
The hardware context allocation is moved into the zone import
routine, as suggested by kib. This is safe because these zone
allocations are always done in a sleepable context.
I have removed the now pointless num_resources tracking,
and added sysctls / tunables to control UMA zone limits
for these tls tags, as well as a tunable to let the
driver pre-allocate tags at boot.
MFC after: 2 weeks
igc.4: Remove non-existent timer tunables
These were removed in a40ecb6f7405 because they do not apply to igc
hardware which uses EITR for interval timing.
Sponsored by: BBOX.io
(cherry picked from commit 8de007ad19dcda5bea9bac9fb2c140e4ed62ba78)
ixgbe: Add support for 1Gbit Active DAC links
1Gbit also emperically works on Active DACs.
Sponsored by: BBOX.io
(cherry picked from commit e38f9257c3fac5cb5a62f62c424a976446ae1220)
igc.4: Remove non-existent timer tunables
These were removed in a40ecb6f7405 because they do not apply to igc
hardware which uses EITR for interval timing.
Sponsored by: BBOX.io
(cherry picked from commit 8de007ad19dcda5bea9bac9fb2c140e4ed62ba78)
