Disabling tcp-data-split on idpf silently fails:
# ethtool -G $NETDEV tcp-data-split off
# ethtool -g $NETDEV | grep 'TCP data split'
TCP data split:on
But it works if you also change 'tx' or 'rx':
# ethtool -G $NETDEV tcp-data-split off tx 256
# ethtool -g $NETDEV | grep 'TCP da
From: Michal Schmidt
Date: Wed, 15 May 2024 11:24:14 +0200
> Disabling tcp-data-split on idpf silently fails:
> # ethtool -G $NETDEV tcp-data-split off
> # ethtool -g $NETDEV | grep 'TCP data split'
> TCP data split:on
>
> But it works if you also change 'tx' or 'rx':
> # ethtool
Daer Alexander, Wojciech,
forgive me for being late to the party, but I just saw the PFCP support
hitting Linus'' git repo in 1b294a1f35616977caddaddf3e9d28e576a1adbc
and was trying to figure out what it is all about. Is there some kind
of article, kernel documentation or other explanation about
Currently the page_frag API is returning 'virtual address'
or 'va' when allocing and expecting 'virtual address' or
'va' as input when freeing.
As we are about to support new use cases that the caller
need to deal with 'struct page' or need to deal with both
'va' and 'struct page'. In order to dif
On 5/15/2024 12:08 AM, Paul Menzel wrote:
Please use imperative mood and fix a typo
I apologize for the oversight. Thank you for your feedback. I'll correct
that.
Thinh Tran
Dear Maintainers,
Thanks for the review and suggestions for my patch.
v8 -> v9
- Rebasing against dev-queue branch of next-queue tree
v7 -> v8
- Added const keyword for the parameter ``mac`` in ice_set_vf_fn_mac()
v6 -> v7
- Addressed Smatch and checkpatch issues
Changing the MAC address of the VFs is currently unsupported via devlink.
Add the function handlers to set and get the HW address for the VFs.
Signed-off-by: Karthik Sundaravel
---
.../ethernet/intel/ice/devlink/devlink_port.c | 59 +-
drivers/net/ethernet/intel/ice/ice_sriov.c
Presented fixes address the following test-case:
* Run xdpsock on queue 10
* change number of combined channels to 20
* observe an error on xdpsock side
The first 2 patches deal with errors, the last one addresses the lack of
traffic.
Larysa Zaremba (3):
ice: remove af_xdp_zc_qps bitmap
ice:
Referenced commit has introduced a bitmap to distinguish between ZC and
copy-mode AF_XDP queues, because xsk_get_pool_from_qid() does not do this
for us.
The bitmap would be especially useful when restoring previous state after
rebuild, if only it was not reallocated in the process. This leads to
Commit 6624e780a577 ("ice: split ice_vsi_setup into smaller functions")
has placed ice_vsi_free_q_vectors() after ice_destroy_xdp_rings() in
the rebuild process. The behaviour of the XDP rings config functions is
context-dependent, so the change of order has led to
ice_destroy_xdp_rings() doing add
ice_pf_dcb_recfg() re-maps queues to vectors with
ice_vsi_map_rings_to_vectors(), which does not restore the previous
state for XDP queues. This leads to no AF_XDP traffic after rebuild.
Map XDP queues to vectors in ice_vsi_map_rings_to_vectors().
Also, move the code around, so XDP queues are mapp
On 5/15/2024 7:22 AM, Karthik Sundaravel wrote:
Caution: This message originated from an External Source. Use proper caution
when opening attachments, clicking links, or responding.
Changing the MAC address of the VFs is currently unsupported via devlink.
Add the function handlers to set an
On Mon, May 13, 2024 at 04:08:12PM +0530, lakshmi.sowjany...@intel.com wrote:
> +Timed I/O and system time are both driven by same hardware clock. The signal
> +is generated with a precision of ~20 nanoseconds. The generated PPS signal
> +is used to synchronize an external device with system clock.
The patch fixes an issue where repeated EEH reports with a single error
on the bus of Intel X710 4-port 10G Base-T adapter in the MSI domain
cause the device to be permanently disabled. It fully resets and
restarts the device when handling the PCI EEH error.
v4: corrected another typos.
v3: moved
Two new functions, i40e_io_suspend() and i40e_io_resume(), have been
introduced. These functions were factored out from the existing
i40e_suspend() and i40e_resume() respectively. This factoring was
done due to concerns about the logic of the I40E_SUSPENSED state, which
caused the device to be un
When EEH events occurs, the callback functions in the i40e, which are
managed by the EEH driver, will completely suspend and resume all IO
operations.
- In the PCI error detected callback, replaced i40e_prep_for_reset()
with i40e_io_suspend(). The change is to fully suspend all I/O
operations
> -Original Message-
> From: Brett Creeley
> Sent: Wednesday, May 15, 2024 9:53 AM
> To: Karthik Sundaravel ; Brandeburg, Jesse
> ; Drewek, Wojciech ;
> sum...@marvell.com; Keller, Jacob E ; Nguyen,
> Anthony L ; da...@davemloft.net;
> eduma...@google.com; k...@kernel.org; pab...@redhat.
17 matches
Mail list logo
