[Intel-wired-lan] [PATCH iwl-next v2] ice: Implement ethtool reset support

Enable ethtool reset support. Ethtool reset flags are mapped to the E810 reset type: PF reset: $ ethtool --reset irq dma filter offload CORE reset: $ ethtool --reset irq-shared dma-shared filter-shared \ offload-shared ram-shared GLOBAL reset: $ ethtool --reset irq-shared dma-shared fi

Re: [Intel-wired-lan] [PATCH] idpf: Acquire the lock before accessing the xn->salt

On 8/3/24 20:25, Manoj Vishwanathan wrote: The transaction salt was being accessed before acquiring the idpf_vc_xn_lock when idpf has to forward the virtchnl reply nits: This text would fit into two lines (the column limit is 75). Missing dot at the very end. Signed-off-by: Manoj Vishwanatha

[Intel-wired-lan] [PATCH iwl-net] ice: Flush FDB entries before reset

Triggering the reset while in switchdev mode causes errors[1]. Rules are already removed by this time because switch content is flushed in case of the reset. We can avoid these errors by clearing the rules early in the reset flow. Remove unnecessary ice_clear_sw_switch_recipes. [1] ice :01:00.

Re: [Intel-wired-lan] [PATCH iwl-next v2] ice: Implement ethtool reset support

On 8/5/24 14:46, Wojciech Drewek wrote: Enable ethtool reset support. Ethtool reset flags are mapped to the E810 reset type: PF reset: $ ethtool --reset irq dma filter offload CORE reset: $ ethtool --reset irq-shared dma-shared filter-shared \ offload-shared ram-shared GLOBAL reset:

[Intel-wired-lan] [PATCH] idpf: Acquire the lock before accessing the xn->salt

The transaction salt was being accessed before acquiring the idpf_vc_xn_lock when idpf has to forward the virtchnl reply Signed-off-by: Manoj Vishwanathan --- drivers/net/ethernet/intel/idpf/idpf_virtchnl.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/etherne

Re: [Intel-wired-lan] [PATCH net-next v12 04/14] mm: page_frag: add '_va' suffix to page_frag API

On 8/3/2024 1:00 AM, Alexander Duyck wrote: As far as your API extension and naming maybe you should look like something like bio_vec and borrow the naming from that since that is essentially what you are passing back and forth is essentially that instead of a page frag which is normally a vi

Re: [Intel-wired-lan] [PATCH net-next v12 04/14] mm: page_frag: add '_va' suffix to page_frag API

Regardless of the API discussion, The nvme-tcp bits look straight-forward: Acked-by: Sagi Grimberg

Re: [Intel-wired-lan] [PATCH v3 iwl-next 4/4] ice: combine cross timestamp functions for E82x and E830

From: Aleksander Lobakin Date: Fri, 26 Jul 2024 15:37 +0200 > > +/** > > + * ice_ptp_set_funcs_e830 - Set specialized functions for E830 support > > + * @pf: Board private structure > > + * > > + * Assign functions to the PTP capabiltiies structure for E830 devices. > > + * Functions which operate

Re: [Intel-wired-lan] [PATCH iwl-net] idpf: remove redundant 'req_vec_chunks' NULL check

> -Original Message- > From: Intel-wired-lan On Behalf Of > Pavan Kumar Linga > Sent: Wednesday, July 24, 2024 2:30 PM > To: intel-wired-...@lists.osuosl.org > Cc: Linga, Pavan Kumar ; Dan Carpenter > > Subject: [Intel-wired-lan] [PATCH iwl-net] idpf: remove redundant > 'req_vec_chunks' N

[Intel-wired-lan] [PATCH] [PATCH iwl-net] idpf: Acquire the lock before accessing the xn->salt

The transaction salt was being accessed before acquiring the idpf_vc_xn_lock when idpf has to forward the virtchnl reply. Fixes: 34c21fa894a1a (“idpf: implement virtchnl transaction manager”) Signed-off-by: Manoj Vishwanathan --- drivers/net/ethernet/intel/idpf/idpf_virtchnl.c | 3 ++- 1 file ch

Re: [Intel-wired-lan] [PATCH iwl-next v2] ice: Implement ethtool reset support

On Mon, 5 Aug 2024 14:46:51 +0200 Wojciech Drewek wrote: > Enable ethtool reset support. Ethtool reset flags are mapped to the > E810 reset type: > PF reset: > $ ethtool --reset irq dma filter offload > CORE reset: > $ ethtool --reset irq-shared dma-shared filter-shared \ > offload-share

Re: [Intel-wired-lan] [PATCH net-next v12 04/14] mm: page_frag: add '_va' suffix to page_frag API

On Sun, Aug 4, 2024 at 10:00 AM Yunsheng Lin wrote: > > On 8/3/2024 1:00 AM, Alexander Duyck wrote: > > >> > >>> > >>> As far as your API extension and naming maybe you should look like > >>> something like bio_vec and borrow the naming from that since that is > >>> essentially what you are passin