Re: [Intel-wired-lan] [PATCH iwl-next v4 6/6] ice: enable LLDP TX for VFs through tc
> -Original Message- > From: Intel-wired-lan On Behalf Of > Simon Horman > Sent: Thursday, February 20, 2025 3:59 PM > To: Zaremba, Larysa > Cc: Nguyen, Anthony L ; intel-wired- > l...@lists.osuosl.org; Kitszel, Przemyslaw ; > Andrew Lunn ; David S. Miller > ; Eric Dumazet ; Jakub > Kicinski ; Paolo Abeni ; > net...@vger.kernel.org; linux-ker...@vger.kernel.org; Michal Swiatkowski > ; Pacuszka, MateuszX > > Subject: Re: [Intel-wired-lan] [PATCH iwl-next v4 6/6] ice: enable LLDP TX for > VFs through tc > > On Fri, Feb 14, 2025 at 09:50:40AM +0100, Larysa Zaremba wrote: > > Only a single VSI can be in charge of sending LLDP frames, sometimes > > it is beneficial to assign this function to a VF, that is possible to > > do with tc capabilities in the switchdev mode. It requires first > > blocking the PF from sending the LLDP frames with a following command: > > > > tc filter add dev egress protocol lldp flower skip_sw action > > drop > > > > Then it becomes possible to configure a forward rule from a VF port > > representor to uplink instead. > > > > tc filter add dev ingress protocol lldp flower skip_sw > > action mirred egress redirect dev > > > > How LLDP exclusivity was done previously is LLDP traffic was blocked > > for a whole port by a single rule and PF was bypassing that. Now at > > least in the switchdev mode, every separate VSI has to have its own > > drop rule. Another complication is the fact that tc does not respect > > when the driver refuses to delete a rule, so returning an error > > results in a HW rule still present with no way to reference it through > > tc. This is addressed by allowing the PF rule to be deleted at any time, but > making the VF forward rule "dormant" > > in such case, this means it is deleted from HW but stays in tc and > > driver's bookkeeping to be restored when drop rule is added back to the PF. > > > > Implement tc configuration handling which enables the user to transmit > > LLDP packets from VF instead of PF. > > > > Reviewed-by: Michal Swiatkowski > > Signed-off-by: Larysa Zaremba > > Reviewed-by: Simon Horman Tested-by: Rafal Romanowski
Re: [Intel-wired-lan] [PATCH net-next v11 0/4] fix the DMA API misuse problem for page_pool
On 3/8/25 3:40 PM, Toke Høiland-Jørgensen wrote: > Yunsheng Lin writes: >> I only took a glance at git code above, it seems reusing the >> _pp_mapping_pad for pp_dma_index seems like a wrong direction >> as mentioned in discussion with Ilias above as the field might >> be used when a page is mmap'ed to user space, and reusing that >> field in 'struct page' seems to disable the tcp_zerocopy feature, >> see the below commit from Eric: >> https://github.com/torvalds/linux/commit/577e4432f3ac810049cb7e6b71f4d96ec7c6e894 >> >> Also, I am not sure if a page_pool owned page can be spliced into the fs >> subsystem yet, but if it does, I am not sure how is reusing the >> page->mapping possible if that page is called in __filemap_add_folio()? >> >> https://elixir.bootlin.com/linux/v6.14-rc5/source/mm/filemap.c#L882 > > Hmm, so I did look at the mapping field, but concluded using it wouldn't > interfere with anything relevant as long as it's reset back to zero > before the page is returned to the page allocator. However, I definitely > missed the TCP zero-copy thing, and other things as well, it would seem > (cf the discussion you referred to above). > > However, I did consider alternatives: AFAICT there should be space in > the pp_magic field (used for the PP_SIGNATURE), so that with a bit of > care we can stick an ID into the upper bits and still avoid ending up > with a value that could look like a valid pointer. > > I didn't implement that initially because I wasn't sure it was > necessary, but seeing as it is, I will take another look at it. I have > one or two other ideas if this turns out not to pan out. Another dumb option would be storing directly the page address in the xarray, and avoid entirely going through an ID. I guess it will use more memory (the array will be more sparse) and will have more overhead, but could be possibly simpler? /P
Re: [Intel-wired-lan] [PATCH net-next 14/16] idpf: add support for XDP on Rx
On Wed, Mar 05, 2025 at 05:21:30PM +0100, Alexander Lobakin wrote:
> Use libeth XDP infra to support running XDP program on Rx polling.
> This includes all of the possible verdicts/actions.
> XDP Tx queues are cleaned only in "lazy" mode when there are less than
> 1/4 free descriptors left on the ring. libeth helper macros to define
> driver-specific XDP functions make sure the compiler could uninline
> them when needed.
> Use __LIBETH_WORD_ACCESS to parse descriptors more efficiently when
> applicable. It really gives some good boosts and code size reduction
> on x86_64.
>
> Co-developed-by: Michal Kubiak
> Signed-off-by: Michal Kubiak
> Signed-off-by: Alexander Lobakin
> ---
> drivers/net/ethernet/intel/idpf/idpf_txrx.h | 4 +-
> drivers/net/ethernet/intel/idpf/xdp.h | 100 -
> drivers/net/ethernet/intel/idpf/idpf_lib.c | 2 +
> drivers/net/ethernet/intel/idpf/idpf_txrx.c | 23 +--
> drivers/net/ethernet/intel/idpf/xdp.c | 155 +++-
> 5 files changed, 264 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/idpf/idpf_txrx.h
> b/drivers/net/ethernet/intel/idpf/idpf_txrx.h
> index e36c55baf23f..5d62074c94b1 100644
> --- a/drivers/net/ethernet/intel/idpf/idpf_txrx.h
> +++ b/drivers/net/ethernet/intel/idpf/idpf_txrx.h
> @@ -684,8 +684,8 @@ struct idpf_tx_queue {
> __cacheline_group_end_aligned(read_mostly);
>
> __cacheline_group_begin_aligned(read_write);
> - u16 next_to_use;
> - u16 next_to_clean;
> + u32 next_to_use;
> + u32 next_to_clean;
>
> union {
> struct {
> diff --git a/drivers/net/ethernet/intel/idpf/xdp.h
> b/drivers/net/ethernet/intel/idpf/xdp.h
> index a72a7638a6ea..fde85528a315 100644
> --- a/drivers/net/ethernet/intel/idpf/xdp.h
> +++ b/drivers/net/ethernet/intel/idpf/xdp.h
> @@ -4,12 +4,9 @@
> #ifndef _IDPF_XDP_H_
> #define _IDPF_XDP_H_
>
> -#include
> +#include
>
> -struct bpf_prog;
> -struct idpf_vport;
> -struct net_device;
> -struct netdev_bpf;
> +#include "idpf_txrx.h"
>
> int idpf_xdp_rxq_info_init_all(const struct idpf_vport *vport);
> void idpf_xdp_rxq_info_deinit_all(const struct idpf_vport *vport);
> @@ -19,6 +16,99 @@ void idpf_copy_xdp_prog_to_qs(const struct idpf_vport
> *vport,
> int idpf_vport_xdpq_get(const struct idpf_vport *vport);
> void idpf_vport_xdpq_put(const struct idpf_vport *vport);
>
> +bool idpf_xdp_tx_flush_bulk(struct libeth_xdp_tx_bulk *bq, u32 flags);
> +
> +/**
> + * idpf_xdp_tx_xmit - produce a single HW Tx descriptor out of XDP desc
> + * @desc: XDP descriptor to pull the DMA address and length from
> + * @i: descriptor index on the queue to fill
> + * @sq: XDP queue to produce the HW Tx descriptor on
> + * @priv: &xsk_tx_metadata_ops on XSk xmit or %NULL
> + */
> +static inline void idpf_xdp_tx_xmit(struct libeth_xdp_tx_desc desc, u32 i,
> + const struct libeth_xdpsq *sq, u64 priv)
> +{
> + struct idpf_flex_tx_desc *tx_desc = sq->descs;
> + u32 cmd;
> +
> + cmd = FIELD_PREP(IDPF_FLEX_TXD_QW1_DTYPE_M,
> + IDPF_TX_DESC_DTYPE_FLEX_L2TAG1_L2TAG2);
> + if (desc.flags & LIBETH_XDP_TX_LAST)
> + cmd |= FIELD_PREP(IDPF_FLEX_TXD_QW1_CMD_M,
> + IDPF_TX_DESC_CMD_EOP);
> + if (priv && (desc.flags & LIBETH_XDP_TX_CSUM))
> + cmd |= FIELD_PREP(IDPF_FLEX_TXD_QW1_CMD_M,
> + IDPF_TX_FLEX_DESC_CMD_CS_EN);
> +
> + tx_desc = &tx_desc[i];
> + tx_desc->buf_addr = cpu_to_le64(desc.addr);
> +#ifdef __LIBETH_WORD_ACCESS
> + *(u64 *)&tx_desc->qw1 = ((u64)desc.len << 48) | cmd;
> +#else
> + tx_desc->qw1.buf_size = cpu_to_le16(desc.len);
> + tx_desc->qw1.cmd_dtype = cpu_to_le16(cmd);
> +#endif
> +}
> +
> +/**
> + * idpf_set_rs_bit - set RS bit on last produced descriptor
> + * @xdpq: XDP queue to produce the HW Tx descriptors on
> + */
> +static inline void idpf_set_rs_bit(const struct idpf_tx_queue *xdpq)
> +{
> + u32 ntu, cmd;
> +
> + ntu = xdpq->next_to_use;
> + if (unlikely(!ntu))
> + ntu = xdpq->desc_count;
> +
> + cmd = FIELD_PREP(IDPF_FLEX_TXD_QW1_CMD_M, IDPF_TX_DESC_CMD_RS);
> +#ifdef __LIBETH_WORD_ACCESS
> + *(u64 *)&xdpq->flex_tx[ntu - 1].q.qw1 |= cmd;
> +#else
> + xdpq->flex_tx[ntu - 1].q.qw1.cmd_dtype |= cpu_to_le16(cmd);
> +#endif
> +}
> +
> +/**
> + * idpf_xdpq_update_tail - update the XDP Tx queue tail register
> + * @xdpq: XDP Tx queue
> + */
> +static inline void idpf_xdpq_update_tail(const struct idpf_tx_queue *xdpq)
> +{
> + dma_wmb();
> + writel_relaxed(xdpq->next_to_use, xdpq->tail);
> +}
> +
> +/**
> + * idpf_xdp_tx_finalize - Update RS bit and bump XDP Tx tail
> + * @_xdpq: XDP Tx queue
> + * @sent: whether any frames were sent
> + * @flush: whether to update RS bit and the tail register
> + *
> + * This function bumps XDP Tx tail and should be called when a batch of
> packets
> + * has been processed in
Re: [Intel-wired-lan] [PATCH net-next 15/16] idpf: add support for .ndo_xdp_xmit()
On Wed, Mar 05, 2025 at 05:21:31PM +0100, Alexander Lobakin wrote:
> Use libeth XDP infra to implement .ndo_xdp_xmit() in idpf.
> The Tx callbacks are reused from XDP_TX code. XDP redirect target
> feature is set/cleared depending on the XDP prog presence, as for now
> we still don't allocate XDP Tx queues when there's no program.
>
> Signed-off-by: Alexander Lobakin
> ---
> drivers/net/ethernet/intel/idpf/xdp.h | 2 ++
> drivers/net/ethernet/intel/idpf/idpf_lib.c | 1 +
> drivers/net/ethernet/intel/idpf/xdp.c | 29 ++
> 3 files changed, 32 insertions(+)
>
> diff --git a/drivers/net/ethernet/intel/idpf/xdp.h
> b/drivers/net/ethernet/intel/idpf/xdp.h
> index fde85528a315..a2ac1b2f334f 100644
> --- a/drivers/net/ethernet/intel/idpf/xdp.h
> +++ b/drivers/net/ethernet/intel/idpf/xdp.h
> @@ -110,5 +110,7 @@ static inline void idpf_xdp_tx_finalize(void *_xdpq, bool
> sent, bool flush)
> void idpf_xdp_set_features(const struct idpf_vport *vport);
>
> int idpf_xdp(struct net_device *dev, struct netdev_bpf *xdp);
> +int idpf_xdp_xmit(struct net_device *dev, int n, struct xdp_frame **frames,
> + u32 flags);
>
> #endif /* _IDPF_XDP_H_ */
> diff --git a/drivers/net/ethernet/intel/idpf/idpf_lib.c
> b/drivers/net/ethernet/intel/idpf/idpf_lib.c
> index 2d1efcb854be..39b9885293a9 100644
> --- a/drivers/net/ethernet/intel/idpf/idpf_lib.c
> +++ b/drivers/net/ethernet/intel/idpf/idpf_lib.c
> @@ -2371,4 +2371,5 @@ static const struct net_device_ops idpf_netdev_ops = {
> .ndo_set_features = idpf_set_features,
> .ndo_tx_timeout = idpf_tx_timeout,
> .ndo_bpf = idpf_xdp,
> + .ndo_xdp_xmit = idpf_xdp_xmit,
> };
> diff --git a/drivers/net/ethernet/intel/idpf/xdp.c
> b/drivers/net/ethernet/intel/idpf/xdp.c
> index abf75e840c0a..1834f217a07f 100644
> --- a/drivers/net/ethernet/intel/idpf/xdp.c
> +++ b/drivers/net/ethernet/intel/idpf/xdp.c
> @@ -357,8 +357,35 @@ LIBETH_XDP_DEFINE_START();
> LIBETH_XDP_DEFINE_TIMER(static idpf_xdp_tx_timer, idpf_clean_xdp_irq);
> LIBETH_XDP_DEFINE_FLUSH_TX(idpf_xdp_tx_flush_bulk, idpf_xdp_tx_prep,
> idpf_xdp_tx_xmit);
> +LIBETH_XDP_DEFINE_FLUSH_XMIT(static idpf_xdp_xmit_flush_bulk,
> idpf_xdp_tx_prep,
> + idpf_xdp_tx_xmit);
> LIBETH_XDP_DEFINE_END();
>
> +/**
> + * idpf_xdp_xmit - send frames queued by ``XDP_REDIRECT`` to this interface
> + * @dev: network device
> + * @n: number of frames to transmit
> + * @frames: frames to transmit
> + * @flags: transmit flags (``XDP_XMIT_FLUSH`` or zero)
> + *
> + * Return: number of frames successfully sent or -errno on error.
> + */
> +int idpf_xdp_xmit(struct net_device *dev, int n, struct xdp_frame **frames,
> + u32 flags)
> +{
> + const struct idpf_netdev_priv *np = netdev_priv(dev);
> + const struct idpf_vport *vport = np->vport;
> +
> + if (unlikely(!netif_carrier_ok(dev) || !vport->link_up))
> + return -ENETDOWN;
> +
> + return libeth_xdp_xmit_do_bulk(dev, n, frames, flags,
> +&vport->txqs[vport->xdp_txq_offset],
> +vport->num_xdp_txq,
Have you considered in some future libeth being stateful where you could
provide some initialization data such as vport->num_xdp_txq which is
rather constant so that we wouldn't have to pass this all the time?
I got a bit puzzled here as it took me some digging that it is only used a
bound check and libeth_xdpsq_id() uses cpu id as an index.
Reviewed-by: Maciej Fijalkowski
> +idpf_xdp_xmit_flush_bulk,
> +idpf_xdp_tx_finalize);
> +}
> +
> void idpf_xdp_set_features(const struct idpf_vport *vport)
> {
> if (!idpf_is_queue_model_split(vport->rxq_model))
> @@ -417,6 +444,8 @@ idpf_xdp_setup_prog(struct idpf_vport *vport, const
> struct netdev_bpf *xdp)
> cfg->user_config.xdp_prog = old;
> }
>
> + libeth_xdp_set_redirect(vport->netdev, vport->xdp_prog);
> +
> return ret;
> }
>
> --
> 2.48.1
>
Re: [Intel-wired-lan] [PATCH net-next 03/16] libeth: add a couple of XDP helpers (libeth_xdp)
On Wed, Mar 05, 2025 at 05:21:19PM +0100, Alexander Lobakin wrote:
> "Couple" is a bit humbly... Add the following functionality to libeth:
>
> * XDP shared queues managing
> * XDP_TX bulk sending infra
> * .ndo_xdp_xmit() infra
> * adding buffers to &xdp_buff
> * running XDP prog and managing its verdict
> * completing XDP Tx buffers
>
> Suggested-by: Maciej Fijalkowski # lots of
> stuff
> Signed-off-by: Alexander Lobakin
Patch is really big and I'm not sure how to trim this TBH to make my
comments bearable. I know this is highly optimized but it's rather hard to
follow with all of the callbacks, defines/aligns and whatnot. Any chance
to chop this commit a bit?
Timers and locking logic could be pulled out to separate patches I think.
You don't ever say what improvement gave you the __LIBETH_WORD_ACCESS
approach. You've put a lot of thought onto this work and I feel like this
is not explained/described thoroughly. What would be nice to see is to
have this in the separate commit as well with a comment like 'this gave me
+X% performance boost on Y workload'. That would be probably a non-zero
effort to restructure it but generally while jumping back and forth
through this code I had a lot of head-scratching moments.
> ---
> drivers/net/ethernet/intel/libeth/Kconfig | 10 +-
> drivers/net/ethernet/intel/libeth/Makefile |7 +-
> include/net/libeth/types.h | 106 +-
> drivers/net/ethernet/intel/libeth/priv.h | 26 +
> include/net/libeth/tx.h| 30 +-
> include/net/libeth/xdp.h | 1827
> drivers/net/ethernet/intel/libeth/tx.c | 38 +
> drivers/net/ethernet/intel/libeth/xdp.c| 431 +
> 8 files changed, 2467 insertions(+), 8 deletions(-)
> create mode 100644 drivers/net/ethernet/intel/libeth/priv.h
> create mode 100644 include/net/libeth/xdp.h
> create mode 100644 drivers/net/ethernet/intel/libeth/tx.c
> create mode 100644 drivers/net/ethernet/intel/libeth/xdp.c
>
> diff --git a/drivers/net/ethernet/intel/libeth/Kconfig
> b/drivers/net/ethernet/intel/libeth/Kconfig
> index 480293b71dbc..d8c4926574fb 100644
> --- a/drivers/net/ethernet/intel/libeth/Kconfig
> +++ b/drivers/net/ethernet/intel/libeth/Kconfig
> @@ -1,9 +1,15 @@
> # SPDX-License-Identifier: GPL-2.0-only
> -# Copyright (C) 2024 Intel Corporation
> +# Copyright (C) 2024-2025 Intel Corporation
>
> config LIBETH
> - tristate
> + tristate "Common Ethernet library (libeth)" if COMPILE_TEST
> select PAGE_POOL
> help
> libeth is a common library containing routines shared between several
> drivers, but not yet promoted to the generic kernel API.
> +
> +config LIBETH_XDP
> + tristate "Common XDP library (libeth_xdp)" if COMPILE_TEST
> + select LIBETH
> + help
> + XDP helpers based on libeth hotpath management.
> diff --git a/drivers/net/ethernet/intel/libeth/Makefile
> b/drivers/net/ethernet/intel/libeth/Makefile
> index 52492b081132..51669840ee06 100644
> --- a/drivers/net/ethernet/intel/libeth/Makefile
> +++ b/drivers/net/ethernet/intel/libeth/Makefile
> @@ -1,6 +1,11 @@
> # SPDX-License-Identifier: GPL-2.0-only
> -# Copyright (C) 2024 Intel Corporation
> +# Copyright (C) 2024-2025 Intel Corporation
>
> obj-$(CONFIG_LIBETH) += libeth.o
>
> libeth-y := rx.o
> +libeth-y += tx.o
> +
> +obj-$(CONFIG_LIBETH_XDP) += libeth_xdp.o
> +
> +libeth_xdp-y += xdp.o
> diff --git a/include/net/libeth/types.h b/include/net/libeth/types.h
> index 603825e45133..cf1d78a9dc38 100644
> --- a/include/net/libeth/types.h
> +++ b/include/net/libeth/types.h
> @@ -1,10 +1,32 @@
> /* SPDX-License-Identifier: GPL-2.0-only */
> -/* Copyright (C) 2024 Intel Corporation */
> +/* Copyright (C) 2024-2025 Intel Corporation */
>
> #ifndef __LIBETH_TYPES_H
> #define __LIBETH_TYPES_H
>
> -#include
> +#include
> +
> +/* Stats */
> +
> +/**
> + * struct libeth_rq_napi_stats - "hot" counters to update in Rx polling loop
> + * @packets: received frames counter
> + * @bytes: sum of bytes of received frames above
> + * @fragments: sum of fragments of received S/G frames
> + * @hsplit: number of frames the device performed the header split for
> + * @raw: alias to access all the fields as an array
> + */
> +struct libeth_rq_napi_stats {
> + union {
> + struct {
> + u32 packets;
> + u32 bytes;
> + u32 fragments;
> + u32 hsplit;
> + };
> + DECLARE_FLEX_ARRAY(u32, raw);
The @raw approach is never used throughout the patchset, right?
Could you explain the reason for introducing this and potential use case?
> + };
> +};
>
> /**
> * struct libeth_sq_napi_stats - "hot" counters to update in Tx completio
Re: [Intel-wired-lan] [PATCH iwl-next v4 3/6] ice: receive LLDP on trusted VFs
> -Original Message- > From: Intel-wired-lan On Behalf Of > Simon Horman > Sent: Thursday, February 20, 2025 3:58 PM > To: Zaremba, Larysa > Cc: Nguyen, Anthony L ; intel-wired- > l...@lists.osuosl.org; Kitszel, Przemyslaw ; > Andrew Lunn ; David S. Miller > ; Eric Dumazet ; Jakub > Kicinski ; Paolo Abeni ; > net...@vger.kernel.org; linux-ker...@vger.kernel.org; Michal Swiatkowski > ; Pacuszka, MateuszX > > Subject: Re: [Intel-wired-lan] [PATCH iwl-next v4 3/6] ice: receive LLDP on > trusted VFs > > On Fri, Feb 14, 2025 at 09:50:37AM +0100, Larysa Zaremba wrote: > > From: Mateusz Pacuszka > > > > When a trusted VF tries to configure an LLDP multicast address, > > configure a rule that would mirror the traffic to this VF, untrusted > > VFs are not allowed to receive LLDP at all, so the request to add LLDP > > MAC address will always fail for them. > > > > Add a forwarding LLDP filter to a trusted VF when it tries to add an > > LLDP multicast MAC address. The MAC address has to be added after > > enabling trust (through restarting the LLDP service). > > > > Signed-off-by: Mateusz Pacuszka > > Co-developed-by: Larysa Zaremba > > Signed-off-by: Larysa Zaremba > > Reviewed-by: Michal Swiatkowski > > Reviewed-by: Simon Horman Tested-by: Rafal Romanowski
Re: [Intel-wired-lan] [PATCH iwl-next v6 02/15] ixgbe: wrap netdev_priv() usage
> -Original Message- > From: Intel-wired-lan On Behalf Of > Jedrzej Jagielski > Sent: Friday, March 7, 2025 7:54 PM > To: intel-wired-...@lists.osuosl.org > Cc: Nguyen, Anthony L ; > net...@vger.kernel.org; ho...@kernel.org; j...@nvidia.com; Kitszel, > Przemyslaw ; Jagielski, Jedrzej > > Subject: [Intel-wired-lan] [PATCH iwl-next v6 02/15] ixgbe: wrap > netdev_priv() usage > > From: Przemek Kitszel > > Wrap use of netdev_priv() in order to change the allocator of the device > private structure from alloc_etherdev_mq() to the devlink in next commit. > > All but one netdev_priv() calls in the whole driver are replaced, the > remaining > one is called on MACVLAN (so not ixgbe) device. > > Signed-off-by: Przemek Kitszel > Signed-off-by: Jedrzej Jagielski > --- > drivers/net/ethernet/intel/ixgbe/ixgbe.h | 5 ++ > .../net/ethernet/intel/ixgbe/ixgbe_dcb_nl.c | 56 +++--- > .../net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 74 +-- > drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c | 12 +-- > .../net/ethernet/intel/ixgbe/ixgbe_ipsec.c| 10 +-- > drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 74 +-- > .../net/ethernet/intel/ixgbe/ixgbe_sriov.c| 16 ++-- > drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c | 2 +- > 8 files changed, 127 insertions(+), 122 deletions(-) > Tested-by: Bharath R
Re: [Intel-wired-lan] [PATCH iwl-next v2] i40e: fix MMIO write access to an invalid page in i40e_clear_hw
On 3/11/25 06:16, Kyungwook Boo wrote:
When the device sends a specific input, an integer underflow can occur, leading
to MMIO write access to an invalid page.
Prevent the integer underflow by changing the type of related variables.
Signed-off-by: Kyungwook Boo
Link:
https://lore.kernel.org/lkml/ffc91764-1142-4ba2-91b6-8c773f6f7...@gmail.com/T/
---
Changes in v2:
- Formatting properly
- Fix variable shadowing
- Link to v1:
https://lore.kernel.org/netdev/55acc5dc-8d5a-45bc-a59c-9304071e4...@gmail.com/
---
drivers/net/ethernet/intel/i40e/i40e_common.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_common.c
b/drivers/net/ethernet/intel/i40e/i40e_common.c
index 370b4bddee44..b11c35e307ca 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_common.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_common.c
@@ -817,10 +817,11 @@ int i40e_pf_reset(struct i40e_hw *hw)
void i40e_clear_hw(struct i40e_hw *hw)
{
u32 num_queues, base_queue;
- u32 num_pf_int;
- u32 num_vf_int;
+ s32 num_pf_int;
+ s32 num_vf_int;
u32 num_vfs;
- u32 i, j;
+ s32 i;
+ u32 j;
u32 val;
u32 eol = 0x7ff;
thank you for localizing the improvement, now the code is more robust,
Reviewed-by: Przemek Kitszel
---
base-commit: 4d872d51bc9d7b899c1f61534e3dbde72613f627
Best regards,
Kyungwook Boo
Re: [Intel-wired-lan] [PATCH iwl-next v3] igc: Change Tx mode for MQPRIO offloading
On 7/3/2025 11:02 pm, Vladimir Oltean wrote: On Mon, Mar 03, 2025 at 10:16:33AM +0100, Kurt Kanzenbach wrote: diff --git a/drivers/net/ethernet/intel/igc/igc.h b/drivers/net/ethernet/intel/igc/igc.h index cd1d7b6c1782352094f6867a31b6958c929bbbf4..16d85bdf55a7e9c412c47acf727bca6bc7154c61 100644 --- a/drivers/net/ethernet/intel/igc/igc.h +++ b/drivers/net/ethernet/intel/igc/igc.h @@ -388,11 +388,9 @@ extern char igc_driver_name[]; #define IGC_FLAG_RX_LEGACYBIT(16) #define IGC_FLAG_TSN_QBV_ENABLED BIT(17) #define IGC_FLAG_TSN_QAV_ENABLED BIT(18) -#define IGC_FLAG_TSN_LEGACY_ENABLEDBIT(19) #define IGC_FLAG_TSN_ANY_ENABLED\ - (IGC_FLAG_TSN_QBV_ENABLED | IGC_FLAG_TSN_QAV_ENABLED | \ -IGC_FLAG_TSN_LEGACY_ENABLED) + (IGC_FLAG_TSN_QBV_ENABLED | IGC_FLAG_TSN_QAV_ENABLED) How do you and Faizal plan to serialize your changes on these flags? You delete IGC_FLAG_TSN_LEGACY_ENABLED and he adds IGC_FLAG_TSN_PREEMPT_ENABLED. From what I’ve experienced before, when there’s a conflict like this, the Intel maintainer handles it and gets both authors to review the resolution (this has happened to both of us before) before they proceed to submit the patch. But if one patch gets merged first, the other person can just rebase and submit a new version ?
Re: [Intel-wired-lan] [PATCH iwl-next v4 4/6] ice: remove headers argument from ice_tc_count_lkups
> -Original Message- > From: Intel-wired-lan On Behalf Of > Simon Horman > Sent: Thursday, February 20, 2025 3:58 PM > To: Zaremba, Larysa > Cc: Nguyen, Anthony L ; intel-wired- > l...@lists.osuosl.org; Kitszel, Przemyslaw ; > Andrew Lunn ; David S. Miller > ; Eric Dumazet ; Jakub > Kicinski ; Paolo Abeni ; > net...@vger.kernel.org; linux-ker...@vger.kernel.org; Michal Swiatkowski > ; Pacuszka, MateuszX > > Subject: Re: [Intel-wired-lan] [PATCH iwl-next v4 4/6] ice: remove headers > argument from ice_tc_count_lkups > > On Fri, Feb 14, 2025 at 09:50:38AM +0100, Larysa Zaremba wrote: > > Remove the headers argument from the ice_tc_count_lkups() function, > > because it is not used anywhere. > > > > Reviewed-by: Michal Swiatkowski > > Signed-off-by: Larysa Zaremba > > Reviewed-by: Simon Horman Tested-by: Rafal Romanowski
Re: [Intel-wired-lan] [PATCH iwl-next v4 2/6] ice: do not add LLDP-specific filter if not necessary
> -Original Message-
> From: Intel-wired-lan On Behalf Of
> Simon Horman
> Sent: Thursday, February 20, 2025 3:57 PM
> To: Zaremba, Larysa
> Cc: Nguyen, Anthony L ; intel-wired-
> l...@lists.osuosl.org; Kitszel, Przemyslaw ;
> Andrew Lunn ; David S. Miller
> ; Eric Dumazet ; Jakub
> Kicinski ; Paolo Abeni ;
> net...@vger.kernel.org; linux-ker...@vger.kernel.org; Michal Swiatkowski
> ; Pacuszka, MateuszX
>
> Subject: Re: [Intel-wired-lan] [PATCH iwl-next v4 2/6] ice: do not add LLDP-
> specific filter if not necessary
>
> On Fri, Feb 14, 2025 at 09:50:36AM +0100, Larysa Zaremba wrote:
> > Commit 34295a3696fb ("ice: implement new LLDP filter command")
> > introduced the ability to use LLDP-specific filter that directs all
> > LLDP traffic to a single VSI. However, current goal is for all trusted
> > VFs to be able to see LLDP neighbors, which is impossible to do with
> > the special filter.
> >
> > Make using the generic filter the default choice and fall back to
> > special one only if a generic filter cannot be added. That way setups
> > with "NVMs where an already existent LLDP filter is blocking the
> > creation of a filter to allow LLDP packets" will still be able to
> > configure software Rx LLDP on PF only, while all other setups would be able
> to forward them to VFs too.
> >
> > Reviewed-by: Michal Swiatkowski
> > Signed-off-by: Larysa Zaremba
>
> Reviewed-by: Simon Horman
>
> ...
>
> > diff --git a/drivers/net/ethernet/intel/ice/ice_common.c
> > b/drivers/net/ethernet/intel/ice/ice_common.c
> > index aaa592ffd2d8..f2e51bacecf8 100644
> > --- a/drivers/net/ethernet/intel/ice/ice_common.c
> > +++ b/drivers/net/ethernet/intel/ice/ice_common.c
> > @@ -6010,15 +6010,21 @@ bool ice_fw_supports_lldp_fltr_ctrl(struct
Tested-by: Rafal Romanowski
Re: [Intel-wired-lan] [PATCH iwl-next v2] i40e: fix MMIO write access to an invalid page in i40e_clear_hw
On Tue, Mar 11, 2025 at 02:16:02PM +0900, Kyungwook Boo wrote:
> When the device sends a specific input, an integer underflow can occur,
> leading
> to MMIO write access to an invalid page.
>
> Prevent the integer underflow by changing the type of related variables.
>
> Signed-off-by: Kyungwook Boo
> Link:
> https://lore.kernel.org/lkml/ffc91764-1142-4ba2-91b6-8c773f6f7...@gmail.com/T/
> ---
> Changes in v2:
> - Formatting properly
> - Fix variable shadowing
> - Link to v1:
> https://lore.kernel.org/netdev/55acc5dc-8d5a-45bc-a59c-9304071e4...@gmail.com/
> ---
> drivers/net/ethernet/intel/i40e/i40e_common.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/i40e/i40e_common.c
> b/drivers/net/ethernet/intel/i40e/i40e_common.c
> index 370b4bddee44..b11c35e307ca 100644
> --- a/drivers/net/ethernet/intel/i40e/i40e_common.c
> +++ b/drivers/net/ethernet/intel/i40e/i40e_common.c
> @@ -817,10 +817,11 @@ int i40e_pf_reset(struct i40e_hw *hw)
> void i40e_clear_hw(struct i40e_hw *hw)
> {
> u32 num_queues, base_queue;
> - u32 num_pf_int;
> - u32 num_vf_int;
> + s32 num_pf_int;
> + s32 num_vf_int;
> u32 num_vfs;
> - u32 i, j;
> + s32 i;
> + u32 j;
> u32 val;
> u32 eol = 0x7ff;
>
> ---
> base-commit: 4d872d51bc9d7b899c1f61534e3dbde72613f627
I see that this addresses the problem at the first link above.
And I'd happy to see it accepted as-is.
Reviewed-by: Simon Horman
But, as an aside, wouldn't it be more appropriate to use generic
types like int and unsigned int for most of the above variables?
Perhaps this could be addressed by a follow-up. Or perhaps that
would just be churn, IDK.
Re: [Intel-wired-lan] [PATCH iwl-next] ice: use DSN instead of PCI BDF for ice_adapter index
On 3/10/25 13:23, Jiri Pirko wrote: Mon, Mar 10, 2025 at 09:40:16AM +0100, przemyslaw.kits...@intel.com wrote: Subject: Re: [PATCH iwl-next] ice: use DSN instead of PCI BDF for ice_adapter index regarding -net vs -next, no one have complained that this bug hurts Wait, so we are now waiting for someone to hit the bug and complain, before we do fix? Does not make any sense to me. no one is waiting for a fix, but it could affect users with weird NVM images, so -next seems reasonable + return (unsigned long)pci_get_dsn(pdev); How do you ensure there is no xarray index collision then you cut the number like this? The reduction occurs only on "32b" systems, which are unlikely to have this device. And any mixing of the upper and lower 4B part still could collide. Passtrough to 32 bit qemu machine? Even how unlikely is that, you are risking a user to hit a bug for newly introduced code without good reason. Why? I will combine the two, by simple xor It is also probably necessary to check if all devices supported by the driver have DSN capability enabled. I will double check on the SoC you have in mind. IMO an NVM issue, will handle this offline
Re: [Intel-wired-lan] [PATCH net-next 06/16] idpf: a use saner limit for default number of queues to allocate
On Wed, Mar 05, 2025 at 05:21:22PM +0100, Alexander Lobakin wrote:
> Currently, the maximum number of queues available for one vport is 16.
> This is hardcoded, but then the function calculating the optimal number
> of queues takes min(16, num_online_cpus()).
> On order to be able to allocate more queues, which will be then used for
nit: s/On/In
> XDP, stop hardcoding 16 and rely on what the device gives us. Instead of
> num_online_cpus(), which is considered suboptimal since at least 2013,
> use netif_get_num_default_rss_queues() to still have free queues in the
> pool.
Should we update older drivers as well?
> nr_cpu_ids number of Tx queues are needed only for lockless XDP sending,
> the regular stack doesn't benefit from that anyhow.
> On a 128-thread Xeon, this now gives me 32 regular Tx queues and leaves
> 224 free for XDP (128 of which will handle XDP_TX, .ndo_xdp_xmit(), and
> XSk xmit when enabled).
>
> Signed-off-by: Alexander Lobakin
> ---
> drivers/net/ethernet/intel/idpf/idpf_txrx.c | 8 +---
> drivers/net/ethernet/intel/idpf/idpf_virtchnl.c | 2 +-
> 2 files changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/idpf/idpf_txrx.c
> b/drivers/net/ethernet/intel/idpf/idpf_txrx.c
> index c15833928ea1..2f221c0abad8 100644
> --- a/drivers/net/ethernet/intel/idpf/idpf_txrx.c
> +++ b/drivers/net/ethernet/intel/idpf/idpf_txrx.c
> @@ -1234,13 +1234,7 @@ int idpf_vport_calc_total_qs(struct idpf_adapter
> *adapter, u16 vport_idx,
> num_req_tx_qs = vport_config->user_config.num_req_tx_qs;
> num_req_rx_qs = vport_config->user_config.num_req_rx_qs;
> } else {
> - int num_cpus;
> -
> - /* Restrict num of queues to cpus online as a default
> - * configuration to give best performance. User can always
> - * override to a max number of queues via ethtool.
> - */
> - num_cpus = num_online_cpus();
> + u32 num_cpus = netif_get_num_default_rss_queues();
>
> dflt_splitq_txq_grps = min_t(int, max_q->max_txq, num_cpus);
> dflt_singleq_txqs = min_t(int, max_q->max_txq, num_cpus);
> diff --git a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
> b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
> index 3d2413b8684f..135af3cc243f 100644
> --- a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
> +++ b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
> @@ -937,7 +937,7 @@ int idpf_vport_alloc_max_qs(struct idpf_adapter *adapter,
> max_tx_q = le16_to_cpu(caps->max_tx_q) / default_vports;
> if (adapter->num_alloc_vports < default_vports) {
> max_q->max_rxq = min_t(u16, max_rx_q, IDPF_MAX_Q);
> - max_q->max_txq = min_t(u16, max_tx_q, IDPF_MAX_Q);
> + max_q->max_txq = min_t(u16, max_tx_q, IDPF_LARGE_MAX_Q);
> } else {
> max_q->max_rxq = IDPF_MIN_Q;
> max_q->max_txq = IDPF_MIN_Q;
> --
> 2.48.1
>
Re: [Intel-wired-lan] [PATCH net-next 00/16] idpf: add XDP support
From: Alexander Lobakin Date: Wed, 5 Mar 2025 17:21:16 +0100 > Add XDP support (w/o XSk yet) to the idpf driver using the libeth_xdp > sublib, which will be then reused in at least iavf and ice. Ok, today I'm back at work. First of all, sorry for the confusion, the subject prefix must've been "PATCH iwl-next" as the whole code is under intel/ and it will go through Tony. I'll change it when sending v2. Now I'll be checking the comments... Thanks, Olek
[Intel-wired-lan] ixgbe: Firmware error and NIC went away.
Hello, We had the ixgbe radios in one of our systems on an overnight test. To my knowledge, we have never seen this particular issue before. Please let me know if you have any ideas on what caused it or how we can get better logs to debug it. We plan to replace the NIC and re-run in case it is hardware issue. The logs below are filtered on 'ixgbe', but I can provide full logs if that would help. This is from 6.11.11 + local patches kernel, but not many changes from stock kernel in the Ethernet stack or driver. root@ct523c-6987:~# grep ixgbe log.txt Mar 07 17:34:48 ct523c-6987 kernel: ixgbe: Intel(R) 10 Gigabit PCI Express Network Driver Mar 07 17:34:48 ct523c-6987 kernel: ixgbe: Copyright (c) 1999-2016 Intel Corporation. Mar 07 17:34:48 ct523c-6987 kernel: ixgbe :15:00.0: Multiqueue Enabled: Rx Queue count = 20, Tx Queue count = 20 XDP Queue count = 0 Mar 07 17:34:48 ct523c-6987 kernel: ixgbe :15:00.0: 31.504 Gb/s available PCIe bandwidth (8.0 GT/s PCIe x4 link) Mar 07 17:34:48 ct523c-6987 kernel: ixgbe :15:00.0: MAC: 4, PHY: 0, PBA No: H86377-005 Mar 07 17:34:48 ct523c-6987 kernel: ixgbe :15:00.0: 3c:fd:fe:e1:c6:c6 Mar 07 17:34:48 ct523c-6987 kernel: ixgbe :15:00.0: Intel(R) 10 Gigabit Network Connection Mar 07 17:34:49 ct523c-6987 kernel: ixgbe :15:00.1: Multiqueue Enabled: Rx Queue count = 20, Tx Queue count = 20 XDP Queue count = 0 Mar 07 17:34:49 ct523c-6987 kernel: ixgbe :15:00.1: 31.504 Gb/s available PCIe bandwidth (8.0 GT/s PCIe x4 link) Mar 07 17:34:49 ct523c-6987 kernel: ixgbe :15:00.1: MAC: 4, PHY: 0, PBA No: H86377-005 Mar 07 17:34:49 ct523c-6987 kernel: ixgbe :15:00.1: 3c:fd:fe:e1:c6:c7 Mar 07 17:34:49 ct523c-6987 kernel: ixgbe :15:00.1: Intel(R) 10 Gigabit Network Connection Mar 07 17:34:49 ct523c-6987 kernel: ixgbe :15:00.0 enp21s0f0: renamed from eth2 Mar 07 17:34:49 ct523c-6987 kernel: ixgbe :15:00.1 enp21s0f1: renamed from eth3 Mar 07 17:34:53 ct523c-6987 kernel: ixgbe :15:00.1 eth3: renamed from enp21s0f1 Mar 07 17:34:53 ct523c-6987 kernel: ixgbe :15:00.0 eth2: renamed from enp21s0f0 Mar 07 17:49:27 ct523c-6987 kernel: ixgbe :15:00.0: registered PHC device on eth2 Mar 07 17:49:27 ct523c-6987 kernel: ixgbe :15:00.0: removed PHC on eth2 Mar 07 17:49:27 ct523c-6987 kernel: ixgbe :15:00.0: registered PHC device on eth2 Mar 07 17:49:28 ct523c-6987 kernel: ixgbe :15:00.0: removed PHC on eth2 Mar 07 17:49:28 ct523c-6987 kernel: ixgbe :15:00.1: registered PHC device on eth3 Mar 07 17:49:28 ct523c-6987 kernel: ixgbe :15:00.0: registered PHC device on eth2 Mar 07 17:49:28 ct523c-6987 kernel: ixgbe :15:00.1: removed PHC on eth3 Mar 07 17:49:29 ct523c-6987 kernel: ixgbe :15:00.1: registered PHC device on eth3 Mar 07 17:49:29 ct523c-6987 kernel: ixgbe :15:00.1: removed PHC on eth3 Mar 07 17:49:29 ct523c-6987 kernel: ixgbe :15:00.1: registered PHC device on eth3 Mar 07 17:49:34 ct523c-6987 kernel: ixgbe :15:00.0 eth2: NIC Link is Up 10 Gbps, Flow Control: RX/TX Mar 07 17:49:34 ct523c-6987 kernel: ixgbe :15:00.1 eth3: NIC Link is Up 10 Gbps, Flow Control: RX/TX Mar 07 17:58:24 ct523c-6987 kernel: ixgbe :15:00.0: removed PHC on eth2 Mar 07 17:58:25 ct523c-6987 kernel: ixgbe :15:00.1: removed PHC on eth3 Mar 07 17:58:48 ct523c-6987 kernel: ixgbe :15:00.0: registered PHC device on eth2 Mar 07 18:00:42 ct523c-6987 kernel: ixgbe :15:00.0 eth2: NIC Link is Up 10 Gbps, Flow Control: RX/TX Mar 07 18:47:08 ct523c-6987 kernel: nfs_acl lockd grace sch_fq_codel sunrpc fuse zram raid1 dm_raid raid456 libcrc32c async_raid6_recov async_memcpy async_pq async_xor xor async_tx raid6_pq xe drm_ttm_helper gpu_sched drm_suballoc_helper drm_gpuvm drm_exec i915 i2c_algo_bit cec rc_core drm_buddy intel_gtt drm_display_helper drm_kms_helper ttm agpgart e1000e igc ixgbe mdio dca hwmon drm xhci_pci mei_wdt i2c_core xhci_pci_renesas video wmi pinctrl_alderlake efivarfs [last unloaded: nfnetlink] Mar 07 18:58:35 ct523c-6987 kernel: ixgbe :15:00.0 eth2: NIC Link is Down Mar 07 18:58:56 ct523c-6987 kernel: ixgbe :15:00.0: removed PHC on eth2 Mar 07 18:58:56 ct523c-6987 kernel: ixgbe :15:00.0: registered PHC device on eth2 Mar 07 18:58:57 ct523c-6987 kernel: ixgbe :15:00.0: removed PHC on eth2 Mar 07 18:58:57 ct523c-6987 kernel: ixgbe :15:00.0: registered PHC device on eth2 Mar 07 18:59:03 ct523c-6987 kernel: ixgbe :15:00.1: registered PHC device on eth3 Mar 07 18:59:03 ct523c-6987 kernel: ixgbe :15:00.1: removed PHC on eth3 Mar 07 18:59:04 ct523c-6987 kernel: ixgbe :15:00.1: registered PHC device on eth3 Mar 07 18:59:08 ct523c-6987 kernel: ixgbe :15:00.0 eth2: NIC Link is Up 10 Gbps, Flow Control: RX/TX Mar 07 18:59:08 ct523c-6987 kernel: ixgbe :15:00.1 eth3: NIC Link is Up 10 Gbps, Flow Control: RX/TX Mar 09 06:08:19 ct523c-6987 kernel: ixgbe :15:00.0: Adapter removed Mar 09 06:08:19 ct523c-6987 kernel: ixgbe :15:00.0:
Re: [Intel-wired-lan] [PATCH net-next v11 1/4] page_pool: introduce page_pool_get_pp() API
On Fri, Mar 7, 2025 at 1:31 AM Yunsheng Lin wrote:
> Introduce page_pool_get_pp() API to avoid caller accessing
> page->pp directly, in order to make the following patch more
> reviewable as the following patch will change page->pp to
> page->pp_item to fix the DMA API misuse problem.
>
> Signed-off-by: Yunsheng Lin
> ---
> drivers/net/ethernet/freescale/fec_main.c | 8 +---
> .../net/ethernet/google/gve/gve_buffer_mgmt_dqo.c | 2 +-
> drivers/net/ethernet/intel/iavf/iavf_txrx.c| 6 --
> drivers/net/ethernet/intel/idpf/idpf_txrx.c| 14 +-
> drivers/net/ethernet/intel/libeth/rx.c | 2 +-
> drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c | 3 ++-
> drivers/net/netdevsim/netdev.c | 6 --
> drivers/net/wireless/mediatek/mt76/mt76.h | 2 +-
> include/net/libeth/rx.h| 3 ++-
> include/net/page_pool/helpers.h| 5 +
> 10 files changed, 34 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/net/ethernet/freescale/fec_main.c
> b/drivers/net/ethernet/freescale/fec_main.c
> index a86cfebedaa8..4ade1553557a 100644
> --- a/drivers/net/ethernet/freescale/fec_main.c
> +++ b/drivers/net/ethernet/freescale/fec_main.c
> @@ -1038,7 +1038,8 @@ static void fec_enet_bd_init(struct net_device *dev)
> struct page *page = txq->tx_buf[i].buf_p;
>
> if (page)
> - page_pool_put_page(page->pp, page,
> 0, false);
> +
> page_pool_put_page(page_pool_get_pp(page),
> + page, 0, false);
> }
>
> txq->tx_buf[i].buf_p = NULL;
> @@ -1576,7 +1577,7 @@ fec_enet_tx_queue(struct net_device *ndev, u16
> queue_id, int budget)
> xdp_return_frame_rx_napi(xdpf);
> } else { /* recycle pages of XDP_TX frames */
> /* The dma_sync_size = 0 as XDP_TX has already
> synced DMA for_device */
> - page_pool_put_page(page->pp, page, 0, true);
> + page_pool_put_page(page_pool_get_pp(page), page,
> 0, true);
> }
>
> txq->tx_buf[index].buf_p = NULL;
> @@ -3343,7 +3344,8 @@ static void fec_enet_free_buffers(struct net_device
> *ndev)
> } else {
> struct page *page = txq->tx_buf[i].buf_p;
>
> - page_pool_put_page(page->pp, page, 0,
> false);
> + page_pool_put_page(page_pool_get_pp(page),
> + page, 0, false);
> }
>
> txq->tx_buf[i].buf_p = NULL;
> diff --git a/drivers/net/ethernet/google/gve/gve_buffer_mgmt_dqo.c
> b/drivers/net/ethernet/google/gve/gve_buffer_mgmt_dqo.c
> index 403f0f335ba6..87422b8828ff 100644
> --- a/drivers/net/ethernet/google/gve/gve_buffer_mgmt_dqo.c
> +++ b/drivers/net/ethernet/google/gve/gve_buffer_mgmt_dqo.c
> @@ -210,7 +210,7 @@ void gve_free_to_page_pool(struct gve_rx_ring *rx,
> if (!page)
> return;
>
> - page_pool_put_full_page(page->pp, page, allow_direct);
> + page_pool_put_full_page(page_pool_get_pp(page), page,
> allow_direct);
> buf_state->page_info.page = NULL;
> }
>
Hi Yunsheng,
FYI, I just submitted a patch that switches the gve driver to using
netmem page_pool API and made the corresponding change to netmem_get_pp API
for the code above.
https://lore.kernel.org/netdev/20250307003905.601175-1-hramamur...@google.com/
FWIW, the spirit of the API change LGTM.
>
> diff --git a/drivers/net/ethernet/intel/iavf/iavf_txrx.c
> b/drivers/net/ethernet/intel/iavf/iavf_txrx.c
> index 422312b8b54a..72f17eaac277 100644
> --- a/drivers/net/ethernet/intel/iavf/iavf_txrx.c
> +++ b/drivers/net/ethernet/intel/iavf/iavf_txrx.c
> @@ -1197,7 +1197,8 @@ static void iavf_add_rx_frag(struct sk_buff *skb,
> const struct libeth_fqe *rx_buffer,
> unsigned int size)
> {
> - u32 hr = rx_buffer->page->pp->p.offset;
> + struct page_pool *pool = page_pool_get_pp(rx_buffer->page);
> + u32 hr = pool->p.offset;
>
> skb_add_rx_frag(skb, skb_shinfo(skb)->nr_frags, rx_buffer->page,
> rx_buffer->offset + hr, size, rx_buffer->truesize);
> @@ -1214,7 +1215,8 @@ static void iavf_add_rx_frag(struct sk_buff *skb,
> static struct sk_buff *iavf_build_skb(const struct libeth_fqe *rx_buffer,
> unsigned int size)
> {
> - u32 hr = rx_buffer->page->pp->p.offset;
> + struct page_pool *pool = page_pool_get_pp(rx_buffer->page);
> + u32 hr = pool->p.offset;
> struct sk_buff *skb;
> void *va;
>
> diff --git a/drivers/net/ethernet/intel/idpf/idpf_txrx.c
Re: [Intel-wired-lan] [PATCH net-next 01/16] libeth: convert to netmem
On Tue, Mar 11, 2025 at 10:23 AM Alexander Lobakin
wrote:
>
> From: Mina Almasry
> Date: Wed, 5 Mar 2025 16:13:32 -0800
>
> > On Wed, Mar 5, 2025 at 8:23 AM Alexander Lobakin
> > wrote:
> >>
> >> Back when the libeth Rx core was initially written, devmem was a draft
> >> and netmem_ref didn't exist in the mainline. Now that it's here, make
> >> libeth MP-agnostic before introducing any new code or any new library
> >> users.
>
> [...]
>
> >> /* Very rare, but possible case. The most common reason:
> >> * the last fragment contained FCS only, which was then
> >> * stripped by the HW.
> >> */
> >> if (unlikely(!len)) {
> >> - libeth_rx_recycle_slow(page);
> >> + libeth_rx_recycle_slow(netmem);
> >
> > I think before this patch this would have expanded to:
> >
> > page_pool_put_full_page(pool, page, true);
> >
> > But now I think it expands to:
> >
> > page_pool_put_full_netmem(netmem_get_pp(netmem), netmem, false);
> >
> > Is the switch from true to false intentional? Is this a slow path so
> > it doesn't matter?
>
> Intentional. unlikely() means it's slowpath already. libeth_rx_recycle()
> is inline, while _slow() is not. I don't want slowpath to be inlined.
> While I was originally writing the code changed here, I didn't pay much
> attention to that, but since then I altered my approach and now try to
> put anything slow out of line to not waste object code.
>
> Also, some time ago I changed PP's approach to decide whether it can
> recycle buffers directly or not. Previously, if that `allow_direct` was
> false, it was always falling back to ptr_ring, but now if `allow_direct`
> is false, it still checks whether it can be recycled directly.
>
Thanks, yes I forgot about that.
> [...]
>
> >> @@ -3122,16 +3122,20 @@ static u32 idpf_rx_hsplit_wa(const struct
> >> libeth_fqe *hdr,
> >> struct libeth_fqe *buf, u32 data_len)
> >> {
> >> u32 copy = data_len <= L1_CACHE_BYTES ? data_len : ETH_HLEN;
> >> + struct page *hdr_page, *buf_page;
> >> const void *src;
> >> void *dst;
> >>
> >> - if (!libeth_rx_sync_for_cpu(buf, copy))
> >> + if (unlikely(netmem_is_net_iov(buf->netmem)) ||
> >> + !libeth_rx_sync_for_cpu(buf, copy))
> >> return 0;
> >>
> >
> > I could not immediately understand why you need a netmem_is_net_iov
> > check here. libeth_rx_sync_for_cpu will delegate to
> > page_pool_dma_sync_netmem_for_cpu which should do the right thing
> > regardless of whether the netmem is a page or net_iov, right? Is this
> > to save some cycles?
>
> If the payload buffer is net_iov, the kernel doesn't have access to it.
> This means, this W/A can't be performed (see memcpy() below the check).
> That's why I exit early explicitly.
> libeth_rx_sync_for_cpu() returns false only if the size is zero.
>
> netmem_is_net_iov() is under unlikely() here, because when using devmem,
> you explicitly configure flow steering, so that only TCP/UDP/whatever
> frames will land on this queue. Such frames are split correctly by
> idpf's HW.
> I need this WA because let's say unfortunately this HW places the whole
> frame to the payload buffer when it's not TCP/UDP/... (see the comment
> above this function).
> For example, it even does so for ICMP, although HW is fully aware of the
> ICMP format. If I was a HW designer of this NIC, I'd instead try putting
> the whole frame to the header buffer, not the payload one. And in
> general, do header split for all known packet types, not just TCP/UDP/..
> But meh... A different story.
>
Makes sense. FWIW:
Reviewed-by: Mina Almasry
--
Thanks,
Mina
Re: [Intel-wired-lan] [PATCH iwl-next v4 5/6] ice: support egress drop rules on PF
> -Original Message- > From: Intel-wired-lan On Behalf Of > Simon Horman > Sent: Thursday, February 20, 2025 3:59 PM > To: Zaremba, Larysa > Cc: Nguyen, Anthony L ; intel-wired- > l...@lists.osuosl.org; Kitszel, Przemyslaw ; > Andrew Lunn ; David S. Miller > ; Eric Dumazet ; Jakub > Kicinski ; Paolo Abeni ; > net...@vger.kernel.org; linux-ker...@vger.kernel.org; Michal Swiatkowski > ; Pacuszka, MateuszX > > Subject: Re: [Intel-wired-lan] [PATCH iwl-next v4 5/6] ice: support egress > drop > rules on PF > > On Fri, Feb 14, 2025 at 09:50:39AM +0100, Larysa Zaremba wrote: > > tc clsact qdisc allows us to add offloaded egress rules with commands > > such as the following one: > > > > tc filter add dev egress protocol lldp flower skip_sw action > > drop > > > > Support the egress rule drop action when added to PF, with a few caveats: > > * in switchdev mode, all PF traffic has to go uplink with an exception for > > LLDP that can be delegated to a single VSI at a time > > * in legacy mode, we cannot delegate LLDP functionality to another VSI, so > > such packets from PF should not be blocked. > > > > Also, simplify the rule direction logic, it was previously derived > > from actions, but actually can be inherited from the tc block (and > > flipped in case of port representors). > > > > Reviewed-by: Michal Swiatkowski > > Signed-off-by: Larysa Zaremba > > Reviewed-by: Simon Horman Tested-by: Rafal Romanowski
Re: [Intel-wired-lan] [PATCH net-next 01/16] libeth: convert to netmem
From: Mina Almasry
Date: Wed, 5 Mar 2025 16:13:32 -0800
> On Wed, Mar 5, 2025 at 8:23 AM Alexander Lobakin
> wrote:
>>
>> Back when the libeth Rx core was initially written, devmem was a draft
>> and netmem_ref didn't exist in the mainline. Now that it's here, make
>> libeth MP-agnostic before introducing any new code or any new library
>> users.
[...]
>> /* Very rare, but possible case. The most common reason:
>> * the last fragment contained FCS only, which was then
>> * stripped by the HW.
>> */
>> if (unlikely(!len)) {
>> - libeth_rx_recycle_slow(page);
>> + libeth_rx_recycle_slow(netmem);
>
> I think before this patch this would have expanded to:
>
> page_pool_put_full_page(pool, page, true);
>
> But now I think it expands to:
>
> page_pool_put_full_netmem(netmem_get_pp(netmem), netmem, false);
>
> Is the switch from true to false intentional? Is this a slow path so
> it doesn't matter?
Intentional. unlikely() means it's slowpath already. libeth_rx_recycle()
is inline, while _slow() is not. I don't want slowpath to be inlined.
While I was originally writing the code changed here, I didn't pay much
attention to that, but since then I altered my approach and now try to
put anything slow out of line to not waste object code.
Also, some time ago I changed PP's approach to decide whether it can
recycle buffers directly or not. Previously, if that `allow_direct` was
false, it was always falling back to ptr_ring, but now if `allow_direct`
is false, it still checks whether it can be recycled directly.
[...]
>> @@ -3122,16 +3122,20 @@ static u32 idpf_rx_hsplit_wa(const struct libeth_fqe
>> *hdr,
>> struct libeth_fqe *buf, u32 data_len)
>> {
>> u32 copy = data_len <= L1_CACHE_BYTES ? data_len : ETH_HLEN;
>> + struct page *hdr_page, *buf_page;
>> const void *src;
>> void *dst;
>>
>> - if (!libeth_rx_sync_for_cpu(buf, copy))
>> + if (unlikely(netmem_is_net_iov(buf->netmem)) ||
>> + !libeth_rx_sync_for_cpu(buf, copy))
>> return 0;
>>
>
> I could not immediately understand why you need a netmem_is_net_iov
> check here. libeth_rx_sync_for_cpu will delegate to
> page_pool_dma_sync_netmem_for_cpu which should do the right thing
> regardless of whether the netmem is a page or net_iov, right? Is this
> to save some cycles?
If the payload buffer is net_iov, the kernel doesn't have access to it.
This means, this W/A can't be performed (see memcpy() below the check).
That's why I exit early explicitly.
libeth_rx_sync_for_cpu() returns false only if the size is zero.
netmem_is_net_iov() is under unlikely() here, because when using devmem,
you explicitly configure flow steering, so that only TCP/UDP/whatever
frames will land on this queue. Such frames are split correctly by
idpf's HW.
I need this WA because let's say unfortunately this HW places the whole
frame to the payload buffer when it's not TCP/UDP/... (see the comment
above this function).
For example, it even does so for ICMP, although HW is fully aware of the
ICMP format. If I was a HW designer of this NIC, I'd instead try putting
the whole frame to the header buffer, not the payload one. And in
general, do header split for all known packet types, not just TCP/UDP/..
But meh... A different story.
>
> --
> Thanks,
> Mina
Thanks!
Olek
[Intel-wired-lan] [PATCH iwl-next 06/10] ice: use bitfields instead of unions for CGU regs
Switch from unions with bitfield structs to definitions with bitfield
masks. This is necessary, because some registers have different
field definitions or even use a different register for the same fields
based on HW type.
Remove unused register fields.
Reviewed-by: Milena Olech
Signed-off-by: Karol Kolacinski
---
drivers/net/ethernet/intel/ice/ice_common.h | 197 +++-
drivers/net/ethernet/intel/ice/ice_tspll.c | 236 +++-
2 files changed, 157 insertions(+), 276 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_common.h
b/drivers/net/ethernet/intel/ice/ice_common.h
index f7952ff3e798..7471d705b108 100644
--- a/drivers/net/ethernet/intel/ice/ice_common.h
+++ b/drivers/net/ethernet/intel/ice/ice_common.h
@@ -39,179 +39,46 @@
#define FEC_RECEIVER_ID_PCS0 (0x33 << FEC_RECV_ID_SHIFT)
#define FEC_RECEIVER_ID_PCS1 (0x34 << FEC_RECV_ID_SHIFT)
-#define ICE_CGU_R9 0x24
-union ice_cgu_r9 {
- struct {
- u32 time_ref_freq_sel : 3;
- u32 clk_eref1_en : 1;
- u32 clk_eref0_en : 1;
- u32 time_ref_en : 1;
- u32 time_sync_en : 1;
- u32 one_pps_out_en : 1;
- u32 clk_ref_synce_en : 1;
- u32 clk_synce1_en : 1;
- u32 clk_synce0_en : 1;
- u32 net_clk_ref1_en : 1;
- u32 net_clk_ref0_en : 1;
- u32 clk_synce1_amp : 2;
- u32 misc6 : 1;
- u32 clk_synce0_amp : 2;
- u32 one_pps_out_amp : 2;
- u32 misc24 : 12;
- };
- u32 val;
-};
+#define ICE_CGU_R9 0x24
+#define ICE_CGU_R9_TIME_REF_FREQ_SEL GENMASK(2, 0)
+#define ICE_CGU_R9_CLK_EREF0_ENBIT(4)
+#define ICE_CGU_R9_TIME_REF_EN BIT(5)
+#define ICE_CGU_R9_TIME_SYNC_ENBIT(6)
+#define ICE_CGU_R9_ONE_PPS_OUT_EN BIT(7)
+#define ICE_CGU_R9_ONE_PPS_OUT_AMP GENMASK(19, 18)
-#define ICE_CGU_R16 0x40
-union ice_cgu_r16 {
- struct {
- u32 synce_remndr : 6;
- u32 synce_phlmt_en : 1;
- u32 misc13 : 17;
- u32 ck_refclkfreq : 8;
- };
- u32 val;
-};
+#define ICE_CGU_R160x40
+#define ICE_CGU_R16_TSPLL_CK_REFCLKFREQGENMASK(31, 24)
-#define ICE_CGU_R19 0x4c
-union ice_cgu_r19 {
- struct {
- u32 fbdiv_intgr : 8;
- u32 fdpll_ulck_thr : 5;
- u32 misc15 : 3;
- u32 ndivratio : 4;
- u32 tspll_iref_ndivratio : 3;
- u32 misc19 : 1;
- u32 japll_ndivratio : 4;
- u32 japll_iref_ndivratio : 3;
- u32 misc27 : 1;
- };
- u32 val;
-};
+#define ICE_CGU_R190x4C
+#define ICE_CGU_R19_TSPLL_FBDIV_INTGR_E82X GENMASK(7, 0)
+#define ICE_CGU_R19_TSPLL_FBDIV_INTGR_E825 GENMASK(9, 0)
+#define ICE_CGU_R19_TSPLL_NDIVRATIOGENMASK(19, 16)
-#define ICE_CGU_R22 0x58
-union ice_cgu_r22 {
- struct {
- u32 fdpll_frac_div_out_nc : 2;
- u32 fdpll_lock_int_for : 1;
- u32 synce_hdov_int_for : 1;
- u32 synce_lock_int_for : 1;
- u32 fdpll_phlead_slip_nc : 1;
- u32 fdpll_acc1_ovfl_nc : 1;
- u32 fdpll_acc2_ovfl_nc : 1;
- u32 synce_status_nc : 6;
- u32 fdpll_acc1f_ovfl : 1;
- u32 misc18 : 1;
- u32 fdpllclk_div : 4;
- u32 time1588clk_div : 4;
- u32 synceclk_div : 4;
- u32 synceclk_sel_div2 : 1;
- u32 fdpllclk_sel_div2 : 1;
- u32 time1588clk_sel_div2 : 1;
- u32 misc3 : 1;
- };
- u32 val;
-};
+#define ICE_CGU_R220x58
+#define ICE_CGU_R22_TIME1588CLK_DIVGENMASK(23, 20)
+#define ICE_CGU_R22_TIME1588CLK_DIV2 BIT(30)
-#define ICE_CGU_R23 0x5C
-union ice_cgu_r23 {
- struct {
- u32 cgupll_fbdiv_intgr : 10;
- u32 ux56pll_fbdiv_intgr : 10;
- u32 misc20 : 4;
- u32 ts_pll_enable : 1;
- u32 time_sync_tspll_align_sel : 1;
- u32 ext_synce_sel : 1;
- u32 ref1588_ck_div : 4;
- u32 time_ref_sel : 1;
+#define ICE_CGU_R230x5C
+#define ICE_CGU_R240x60
+#define ICE_CGU_R24_FBDIV_FRAC GENMASK(21, 0)
+#define ICE_CGU_R23_R24_TSPLL_ENABLE BIT(24)
+#define ICE_CGU_R23_R24_REF1588_CK_DIV GENMASK(30, 27)
+#define ICE_CGU_R23_R24_TIME_REF_SEL BIT(31)
- };
- u32 val;
-};
+#define ICE_CGU_BW_TDC 0x31C
+#define ICE_CGU_BW_TDC_PLLLOCK_SEL GENMASK(30, 29)
-#define ICE_CGU_R24 0x60
-union ice_cgu_r24 {
- struct {
- u32 fbdiv_frac : 22;
- u32 misc20 : 2;
- u32 ts_pll_enable : 1;
- u32 time_sync_tspll_align_sel :
[Intel-wired-lan] [PATCH net 2/5] renesas: reject PTP_STRICT_FLAGS as unsupported
The ravb_ptp_extts() function checks the flags coming from the
PTP_EXTTS_REQUEST ioctl, to ensure that future flags are not accepted on
accident.
This was updated to 'honor' the PTP_STRICT_FLAGS in commit 6138e687c7b6
("ptp: Introduce strict checking of external time stamp options.").
However, the driver does not *actually* validate the flags.
I originally fixed this driver to reject future flags in commit
592025a03b34 ("renesas: reject unsupported external timestamp flags"). It
is still unclear whether this hardware timestamps the rising, falling, or
both edges of the input signal.
Accepting requests with PTP_STRICT_FLAGS is a bug, as this could lead to
users mistakenly assuming a request with PTP_RISING_EDGE actually
timestamps the rising edge only.
Reject requests with PTP_STRICT_FLAGS (and hence all PTP_EXTTS_REQUEST2
requests) until someone with access to the datasheet or hardware knowledge
can confirm the timestamping behavior and update this driver.
Fixes: 6138e687c7b6 ("ptp: Introduce strict checking of external time stamp
options.")
Signed-off-by: Jacob Keller
---
drivers/net/ethernet/renesas/ravb_ptp.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/renesas/ravb_ptp.c
b/drivers/net/ethernet/renesas/ravb_ptp.c
index
6e4ef7af27bf31ab2aad8e06a65e0ede6046e3c0..b4365906669f3bd40953813e263aeaafd2e1eb70
100644
--- a/drivers/net/ethernet/renesas/ravb_ptp.c
+++ b/drivers/net/ethernet/renesas/ravb_ptp.c
@@ -179,8 +179,7 @@ static int ravb_ptp_extts(struct ptp_clock_info *ptp,
/* Reject requests with unsupported flags */
if (req->flags & ~(PTP_ENABLE_FEATURE |
PTP_RISING_EDGE |
- PTP_FALLING_EDGE |
- PTP_STRICT_FLAGS))
+ PTP_FALLING_EDGE))
return -EOPNOTSUPP;
if (req->index)
--
2.48.1.397.gec9d649cc640
Re: [Intel-wired-lan] [PATCH iwl-next v2 2/4] igb: Link queues to NAPI instances
On Fri, Mar 07, 2025 at 02:03:44PM -0800, Tony Nguyen wrote: > On 2/17/2025 3:31 AM, Kurt Kanzenbach wrote: > > ... > > > diff --git a/drivers/net/ethernet/intel/igb/igb_xsk.c > > b/drivers/net/ethernet/intel/igb/igb_xsk.c > > index > > 157d43787fa0b55a74714f69e9e7903b695fcf0a..a5ad090dfe94b6afc8194fe39d28cdd51c7067b0 > > 100644 > > --- a/drivers/net/ethernet/intel/igb/igb_xsk.c > > +++ b/drivers/net/ethernet/intel/igb/igb_xsk.c > > @@ -45,6 +45,7 @@ static void igb_txrx_ring_disable(struct igb_adapter > > *adapter, u16 qid) > > synchronize_net(); > > /* Rx/Tx share the same napi context. */ > > + igb_set_queue_napi(adapter, qid, NULL); > > napi_disable(&rx_ring->q_vector->napi); > > igb_clean_tx_ring(tx_ring); > > @@ -78,6 +79,7 @@ static void igb_txrx_ring_enable(struct igb_adapter > > *adapter, u16 qid) > > /* Rx/Tx share the same napi context. */ > > napi_enable(&rx_ring->q_vector->napi); > > + igb_set_queue_napi(adapter, qid, &rx_ring->q_vector->napi); > > } > > struct xsk_buff_pool *igb_xsk_pool(struct igb_adapter *adapter, > > I believe Joe's fix/changes [1] need to be done here as well? > > Thanks, > Tony > > [1] > https://lore.kernel.org/intel-wired-lan/9ddf6293-6cb0-47ea-a0e7-cad7d33c2...@intel.com/T/#m863614df1fb3d1980ad09016b1c9ef4e2f0b074e Yes, the code above should be dropped. Sorry I missed that during review - thanks for catching that, Tony. Kurt: when you respin this to fix what Tony mentioned, can you also run the test mentioned above? NETIF=eth0 ./tools/testing/selftests/drivers/net/queues.py
Re: [Intel-wired-lan] [PATCH iwl-next v3 4/4] ixgbe: add E610 .set_phys_id() callback implementation
> -Original Message- > From: Intel-wired-lan On Behalf Of > Jedrzej Jagielski > Sent: Monday, March 3, 2025 5:37 PM > To: intel-wired-...@lists.osuosl.org > Cc: Nguyen, Anthony L ; > net...@vger.kernel.org; and...@lunn.ch; pmen...@molgen.mpg.de; > Jagielski, Jedrzej ; Loktionov, Aleksandr > ; Michal Swiatkowski > > Subject: [Intel-wired-lan] [PATCH iwl-next v3 4/4] ixgbe: add E610 > .set_phys_id() callback implementation > > Legacy implementation of .set_phys_id() ethtool callback is not applicable for > E610 device. > > Add new implementation which uses 0x06E9 command by calling > ixgbe_aci_set_port_id_led(). > > Reviewed-by: Aleksandr Loktionov > Reviewed-by: Michal Swiatkowski > Signed-off-by: Jedrzej Jagielski > --- > v3: move the #defines related to ixgbe_aci_cmd_set_port_id_led out of the > struct definition > --- > drivers/net/ethernet/intel/ixgbe/ixgbe_e610.c | 29 +++ > drivers/net/ethernet/intel/ixgbe/ixgbe_e610.h | 1 + > .../net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 22 +- > .../ethernet/intel/ixgbe/ixgbe_type_e610.h| 14 + > 4 files changed, 65 insertions(+), 1 deletion(-) > Tested-by: Bharath R
Re: [Intel-wired-lan] [PATCH iwl-next v4 1/6] ice: fix check for existing switch rule
> -Original Message- > From: Intel-wired-lan On Behalf Of > Simon Horman > Sent: Thursday, February 20, 2025 3:56 PM > To: Zaremba, Larysa > Cc: Nguyen, Anthony L ; intel-wired- > l...@lists.osuosl.org; Kitszel, Przemyslaw ; > Andrew Lunn ; David S. Miller > ; Eric Dumazet ; Jakub > Kicinski ; Paolo Abeni ; > net...@vger.kernel.org; linux-ker...@vger.kernel.org; Michal Swiatkowski > ; Pacuszka, MateuszX > > Subject: Re: [Intel-wired-lan] [PATCH iwl-next v4 1/6] ice: fix check for > existing > switch rule > > On Fri, Feb 14, 2025 at 09:50:35AM +0100, Larysa Zaremba wrote: > > From: Mateusz Pacuszka > > > > In case the rule already exists and another VSI wants to subscribe to > > it new VSI list is being created and both VSIs are moved to it. > > Currently, the check for already existing VSI with the same rule is > > done based on fdw_id.hw_vsi_id, which applies only to LOOKUP_RX flag. > > Change it to vsi_handle. This is software VSI ID, but it can be > > applied here, because vsi_map itself is also based on it. > > > > Additionally change return status in case the VSI already exists in > > the VSI map to "Already exists". Such case should be handled by the caller. > > FWIIW, I might have made this two patches, but I don't feel particularly > strongly about it. > > > > > Signed-off-by: Mateusz Pacuszka > > Reviewed-by: Przemek Kitszel > > Reviewed-by: Michal Swiatkowski > > Signed-off-by: Larysa Zaremba > > Reviewed-by: Simon Horman Tested-by: Rafal Romanowski
Re: [Intel-wired-lan] [PATCH iwl-next v6] ice: Add E830 checksum offload support
> -Original Message- > From: Intel-wired-lan On Behalf Of Paul > Greenwalt > Sent: 18 December 2024 14:42 > To: intel-wired-...@lists.osuosl.org > Cc: k...@kernel.org; net...@vger.kernel.org; Greenwalt, Paul > ; Alice Michael ; Eric > Joyner > Subject: [Intel-wired-lan] [PATCH iwl-next v6] ice: Add E830 checksum offload > support > > E830 supports raw receive and generic transmit checksum offloads. > > Raw receive checksum support is provided by hardware calculating the checksum > over the whole packet, regardless of type. The calculated checksum is > provided to driver in the Rx flex descriptor. Then the driver assigns the > checksum to skb->csum and sets skb->ip_summed to CHECKSUM_COMPLETE. > > Generic transmit checksum support is provided by hardware calculating the > checksum given two offsets: the start offset to begin checksum calculation, > and the offset to insert the calculated checksum in the packet. Support is > advertised to the stack using NETIF_F_HW_CSUM feature. > > E830 has the following limitations when both generic transmit checksum > offload and TCP Segmentation Offload (TSO) are enabled: > > 1. Inner packet header modification is not supported. This restriction > includes the inability to alter TCP flags, such as the push flag. As a > result, this limitation can impact the receiver's ability to coalesce > packets, potentially degrading network throughput. > 2. The Maximum Segment Size (MSS) is limited to 1023 bytes, which prevents > support of Maximum Transmission Unit (MTU) greater than 1063 bytes. > > Therefore NETIF_F_HW_CSUM and NETIF_F_ALL_TSO features are mutually > exclusive. NETIF_F_HW_CSUM hardware feature support is indicated but is not > enabled by default. Instead, IP checksums and NETIF_F_ALL_TSO are > the > defaults. Enforcement of mutual exclusivity of NETIF_F_HW_CSUM and > NETIF_F_ALL_TSO is done in ice_set_features(). Mutual exclusivity of IP > checksums and NETIF_F_HW_CSUM is handled by netdev_fix_features(). > > When NETIF_F_HW_CSUM is requested the provided skb->csum_start and > skb->csum_offset are passed to hardware in the Tx context descriptor > generic checksum (GCS) parameters. Hardware calculates the 1's complement > from skb->csum_start to the end of the packet, and inserts the result in the > packet at skb->csum_offset. > > Co-developed-by: Alice Michael > Signed-off-by: Alice Michael > Co-developed-by: Eric Joyner > Signed-off-by: Eric Joyner > Signed-off-by: Paul Greenwalt > --- > Changelog: > v1->v2 > - Update commit message with additional details. > - Add newlines, and add params around > - Return early from ice_fix_features() to avoid extra indentation and > large if block. > - Move and change some defines. > - replace htons and le16_t_cpu with swap16. > - Use FIELD_PREP where possible. > - Removed checksum valid bit check STATUS1_L2TAG2P_S. This check is not > needed since there is no situation which will return an error. > v2->v3 > - Minor fixes in commit message. > - Removed unused register defines in ice_hw_autogen.h. > - Moved GCS and TSO feature fix to helper function > ice_fix_features_gcs(), and updated logic. > - Update to align naming with related flags. > v3->v4 > - Move a check for GCS and TSO mutual exclusivity from > ice_fix_features() to ice_set_features(). > v4->v5 > - Remove lingering GCS and TSO mutual exclusivity comments and code in > ice_fix_features(). > - Remove unused variable ICE_TX_FLAGS_RING_GCS. > - Remove Tested-by and Signed-off-by tag due to changes to patch. > - Use ICE_TX_GCS_DESC_TYPE_M and ICE_TX_GCS_DESC_CSUM_PSH in > ice_tx_csum() to set the GCS decriptor field type. > v5->v6 > - Fix build error. > --- > drivers/net/ethernet/intel/ice/ice.h | 1 + > .../net/ethernet/intel/ice/ice_lan_tx_rx.h| 9 +-- > drivers/net/ethernet/intel/ice/ice_lib.c | 8 +- > drivers/net/ethernet/intel/ice/ice_main.c | 18 + > drivers/net/ethernet/intel/ice/ice_txrx.c | 27 ++- > drivers/net/ethernet/intel/ice/ice_txrx.h | 2 ++ > drivers/net/ethernet/intel/ice/ice_txrx_lib.c | 26 ++ > 7 files changed, 87 insertions(+), 4 deletions(-) > Tested-by: Rinitha S (A Contingent worker at Intel)
[Intel-wired-lan] [PATCH 1/2] net: intel: Remove unnecessary static variable initialization
Static variables in C are implicitly initialized to zero, so there is no need to explicitly set and to 0. This change removes the redundant initialization Signed-off-by: Joao Bonifacio --- drivers/net/ethernet/intel/e100.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/intel/e100.c b/drivers/net/ethernet/intel/e100.c index 3a5bbda235cb..f5d32663a89a 100644 --- a/drivers/net/ethernet/intel/e100.c +++ b/drivers/net/ethernet/intel/e100.c @@ -167,8 +167,8 @@ MODULE_FIRMWARE(FIRMWARE_D101S); MODULE_FIRMWARE(FIRMWARE_D102E); static int debug = 3; -static int eeprom_bad_csum_allow = 0; -static int use_io = 0; +static int eeprom_bad_csum_allow; +static int use_io; module_param(debug, int, 0); module_param(eeprom_bad_csum_allow, int, 0444); module_param(use_io, int, 0444); -- 2.48.1
[Intel-wired-lan] [PATCH iwl-next 00/10] ice: Separate TSPLL from PTP and clean up
Separate TSPLL related functions and definitions from all PTP-related files and clean up the code by implementing multiple helpers. Adjust TSPLL wait times and fall back to TCXO on lock failure to ensure proper init flow of TSPLL. Karol Kolacinski (10): ice: move TSPLL functions to a separate file ice: rename TSPLL and CGU functions and definitions ice: use designated initializers for TSPLL consts ice: add TSPLL log config helper ice: add ICE_READ/WRITE_CGU_REG_OR_DIE helpers ice: use bitfields instead of unions for CGU regs ice: add multiple TSPLL helpers ice: wait before enabling TSPLL ice: fall back to TCXO on TSPLL lock fail ice: move TSPLL init calls to ice_ptp.c drivers/net/ethernet/intel/ice/Makefile | 2 +- drivers/net/ethernet/intel/ice/ice.h | 1 + drivers/net/ethernet/intel/ice/ice_cgu_regs.h | 181 -- drivers/net/ethernet/intel/ice/ice_common.c | 69 ++- drivers/net/ethernet/intel/ice/ice_common.h | 58 ++ drivers/net/ethernet/intel/ice/ice_ptp.c | 14 +- .../net/ethernet/intel/ice/ice_ptp_consts.h | 177 +- drivers/net/ethernet/intel/ice/ice_ptp_hw.c | 566 +- drivers/net/ethernet/intel/ice/ice_ptp_hw.h | 54 +- drivers/net/ethernet/intel/ice/ice_tspll.c| 508 drivers/net/ethernet/intel/ice/ice_tspll.h| 28 + drivers/net/ethernet/intel/ice/ice_type.h | 20 +- 12 files changed, 698 insertions(+), 980 deletions(-) delete mode 100644 drivers/net/ethernet/intel/ice/ice_cgu_regs.h create mode 100644 drivers/net/ethernet/intel/ice/ice_tspll.c create mode 100644 drivers/net/ethernet/intel/ice/ice_tspll.h base-commit: daa2036c311e81ee32f88257e3dfd4985f79 -- 2.48.1
Re: [Intel-wired-lan] [PATCH iwl-next v2] ice: add E830 Earliest TxTime First Offload support
Hi Paul,
kernel test robot noticed the following build warnings:
[auto build test WARNING on tnguy-next-queue/dev-queue]
url:
https://github.com/intel-lab-lkp/linux/commits/Paul-Greenwalt/ice-add-E830-Earliest-TxTime-First-Offload-support/20250312-051400
base: https://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue.git
dev-queue
patch link:
https://lore.kernel.org/r/20250311132327.76804-1-paul.greenwalt%40intel.com
patch subject: [PATCH iwl-next v2] ice: add E830 Earliest TxTime First Offload
support
config: s390-allyesconfig
(https://download.01.org/0day-ci/archive/20250312/202503121005.igev5eau-...@intel.com/config)
compiler: s390-linux-gcc (GCC) 14.2.0
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20250312/202503121005.igev5eau-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202503121005.igev5eau-...@intel.com/
All warnings (new ones prefixed by >>):
drivers/net/ethernet/intel/ice/ice_base.c: In function 'ice_vsi_cfg_txq':
>> drivers/net/ethernet/intel/ice/ice_base.c:1023:46: warning: passing argument
>> 1 of 'ice_calc_txq_handle' discards 'const' qualifier from pointer target
>> type [-Wdiscarded-qualifiers]
1023 | ring->q_handle = ice_calc_txq_handle(vsi, ring, tc);
| ^~~
drivers/net/ethernet/intel/ice/ice_base.c:245:48: note: expected 'struct
ice_vsi *' but argument is of type 'const struct ice_vsi *'
245 | static u16 ice_calc_txq_handle(struct ice_vsi *vsi, struct
ice_tx_ring *ring, u8 tc)
|^~~
vim +1023 drivers/net/ethernet/intel/ice/ice_base.c
eff380aaffedb27 Anirudh Venkataramanan 2019-10-24 974
eff380aaffedb27 Anirudh Venkataramanan 2019-10-24 975 /**
eff380aaffedb27 Anirudh Venkataramanan 2019-10-24 976 * ice_vsi_cfg_txq -
Configure single Tx queue
eff380aaffedb27 Anirudh Venkataramanan 2019-10-24 977 * @vsi: the VSI that
queue belongs to
eff380aaffedb27 Anirudh Venkataramanan 2019-10-24 978 * @ring: Tx ring to
be configured
51900dfcf194b39 Paul Greenwalt 2025-03-11 979 * @tstamp_ring: time
stamp ring to be configured
eff380aaffedb27 Anirudh Venkataramanan 2019-10-24 980 * @qg_buf: queue
group buffer
51900dfcf194b39 Paul Greenwalt 2025-03-11 981 * @txtime_qg_buf: Tx
Time queue group buffer
51900dfcf194b39 Paul Greenwalt 2025-03-11 982 *
51900dfcf194b39 Paul Greenwalt 2025-03-11 983 * Return: 0 on
success and a negative value on error.
eff380aaffedb27 Anirudh Venkataramanan 2019-10-24 984 */
a292ba981324ec7 Maciej Fijalkowski 2024-01-23 985 static int
51900dfcf194b39 Paul Greenwalt 2025-03-11 986 ice_vsi_cfg_txq(const
struct ice_vsi *vsi, struct ice_tx_ring *ring,
51900dfcf194b39 Paul Greenwalt 2025-03-11 987 struct
ice_tx_ring *tstamp_ring,
51900dfcf194b39 Paul Greenwalt 2025-03-11 988 struct
ice_aqc_add_tx_qgrp *qg_buf,
51900dfcf194b39 Paul Greenwalt 2025-03-11 989 struct
ice_aqc_set_txtime_qgrp *txtime_qg_buf)
eff380aaffedb27 Anirudh Venkataramanan 2019-10-24 990 {
66486d8943bac36 Bruce Allan2020-06-29 991 u8 buf_len =
struct_size(qg_buf, txqs, 1);
eff380aaffedb27 Anirudh Venkataramanan 2019-10-24 992 struct
ice_tlan_ctx tlan_ctx = { 0 };
eff380aaffedb27 Anirudh Venkataramanan 2019-10-24 993 struct
ice_aqc_add_txqs_perq *txq;
0754d65bd4be5bb Kiran Patil2021-10-15 994 struct
ice_channel *ch = ring->ch;
eff380aaffedb27 Anirudh Venkataramanan 2019-10-24 995 struct ice_pf
*pf = vsi->back;
7e34786a74e1403 Bruce Allan2020-05-15 996 struct ice_hw
*hw = &pf->hw;
5e24d5984c805c6 Tony Nguyen2021-10-07 997 int status;
eff380aaffedb27 Anirudh Venkataramanan 2019-10-24 998 u16 pf_q;
e75d1b2c3731999 Maciej Fijalkowski 2019-10-24 999 u8 tc;
eff380aaffedb27 Anirudh Venkataramanan 2019-10-24 1000
634da4c118434cf Benita Bose2021-03-02 1001 /* Configure
XPS */
634da4c118434cf Benita Bose2021-03-02 1002
ice_cfg_xps_tx_ring(ring);
634da4c118434cf Benita Bose2021-03-02 1003
eff380aaffedb27 Anirudh Venkataramanan 2019-10-24 1004 pf_q =
ring->reg_idx;
eff380aaffedb27 Anirudh Venkataramanan 2019-10-24 1005
ice_setup_tx_ctx(ring, &tlan_ctx, pf_q);
eff380aaffedb27 Anirudh Venkataramanan 2019-10-24 1006 /* copy context
contents into the qg_buf */
eff380aaffedb27 Anirudh Venkataramanan 2019-10-24 1007
qg_buf->txqs[0].txq_id = cpu_to_le16(pf_q);
dc4305be467a6f8 Jacob Keller 2024-12-10 1008
ice_p
Re: [Intel-wired-lan] [PATCH net 1/5] igb: reject invalid external timestamp requests for 82580-based HW
> -Original Message-
> From: Michal Swiatkowski
> Sent: Monday, March 10, 2025 11:04 PM
> To: Keller, Jacob E
> Cc: Nguyen, Anthony L ; Kitszel, Przemyslaw
> ; Andrew Lunn ; David
> S. Miller ; Eric Dumazet ;
> Jakub Kicinski ; Paolo Abeni ; Richard
> Cochran ; Ruud Bos ; Paul
> Barker ; Niklas Söderlund
> ; Bryan Whitehead
> ; unglinuxdri...@microchip.com; Raju
> Lakkaraju ; Florian Fainelli
> ; Broadcom internal kernel review list kernel-feedback-l...@broadcom.com>; Andrew Lunn ; Heiner
> Kallweit ; Russell King ;
> Jonathan Lemon ; Lasse Johnsen
> ; Vadim Fedorenko ; intel-
> wired-...@lists.osuosl.org; net...@vger.kernel.org; linux-renesas-
> s...@vger.kernel.org
> Subject: Re: [PATCH net 1/5] igb: reject invalid external timestamp requests
> for
> 82580-based HW
>
> On Mon, Mar 10, 2025 at 03:16:36PM -0700, Jacob Keller wrote:
> > The igb_ptp_feature_enable_82580 function correctly checks that unknown
> > flags are not passed to the function. However, it does not actually check
> > PTP_RISING_EDGE or PTP_FALLING_EDGE when configuring the external
> timestamp
> > function.
> >
> > The data sheet for the 82580 product says:
> >
> > Upon a change in the input level of one of the SDP pins that was
> > configured to detect Time stamp events using the TSSDP register, a time
> > stamp of the system time is captured into one of the two auxiliary time
> > stamp registers (AUXSTMPL/H0 or AUXSTMPL/H1).
> >
> > For example to define timestamping of events in the AUXSTMPL0 and
> > AUXSTMPH0 registers, Software should:
> >
> > 1. Set the TSSDP.AUX0_SDP_SEL field to select the SDP pin that detects
> > the level change and set the TSSDP.AUX0_TS_SDP_EN bit to 1.
> >
> > 2. Set the TSAUXC.EN_TS0 bit to 1 to enable timestamping
> >
> > The same paragraph is in the i350 and i354 data sheets.
> >
> > The wording implies that the time stamps are captured at any level change.
> > There does not appear to be any way to only timestamp one edge of the
> > signal.
> >
> > Reject requests which do not set both PTP_RISING_EDGE and
> PTP_FALLING_EDGE
> > when operating under PTP_STRICT_FLAGS mode via PTP_EXTTS_REQUEST2.
> >
> > Fixes: 38970eac41db ("igb: support EXTTS on 82580/i354/i350")
> > Signed-off-by: Jacob Keller
> > ---
> > drivers/net/ethernet/intel/igb/igb_ptp.c | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/drivers/net/ethernet/intel/igb/igb_ptp.c
> b/drivers/net/ethernet/intel/igb/igb_ptp.c
> > index
> f9457055612004c10f74379122063e8136fe7d76..b89ef4538a18d7ca11325ddc1594
> 4a878f4d807e 100644
> > --- a/drivers/net/ethernet/intel/igb/igb_ptp.c
> > +++ b/drivers/net/ethernet/intel/igb/igb_ptp.c
> > @@ -509,6 +509,11 @@ static int igb_ptp_feature_enable_82580(struct
> ptp_clock_info *ptp,
> > PTP_STRICT_FLAGS))
> > return -EOPNOTSUPP;
> >
> > + /* Both the rising and falling edge are timstamped */
> > + if (rq->extts.flags & PTP_STRICT_FLAGS &&
> > + (rq->extts.flags & PTP_EXTTS_EDGES) != PTP_EXTTS_EDGES)
> > + return -EOPNOTSUPP;
> > +
> > if (on) {
> > pin = ptp_find_pin(igb->ptp_clock, PTP_PF_EXTTS,
> >rq->extts.index);
>
> Thanks for fixing
> Reviewed-by: Michal Swiatkowski
>
> In igb_ptp_feature_enable_i210() there is the same check for both edges
> but also PTP_ENABLE_FEATURE is tested. There is no need for it here, or
> it is redundant even in i210?
>
Hmm. It might be required, because requests to disable the clock won't have
PTP_FEATURE_ENABLED set, and might have the edges cleared, which would prevent
you from disabling the output..? I'll have to see what the kernel does when it
disables the function.
[Intel-wired-lan] [iwl-next v1 8/8] i40e: use libie_aq_str
There is no need to store the err string in hw->err_str. Simplify it and
use common helper. hw->err_str is still used for other purpouse.
It should be marked that previously for unknown error the numeric value
was passed as a string. Now the "LIBIE_AQ_RC_UNKNOWN" is used for such
cases.
Add libie_aminq module in i40e Kconfig.
Reviewed-by: Przemek Kitszel
Reviewed-by: Larysa Zaremba
Signed-off-by: Michal Swiatkowski
---
drivers/net/ethernet/intel/Kconfig| 1 +
.../net/ethernet/intel/i40e/i40e_prototype.h | 1 -
drivers/net/ethernet/intel/i40e/i40e_client.c | 7 +-
drivers/net/ethernet/intel/i40e/i40e_common.c | 52 -
drivers/net/ethernet/intel/i40e/i40e_dcb_nl.c | 8 +-
.../net/ethernet/intel/i40e/i40e_ethtool.c| 22 +-
drivers/net/ethernet/intel/i40e/i40e_main.c | 209 +++---
drivers/net/ethernet/intel/i40e/i40e_nvm.c| 2 +-
.../ethernet/intel/i40e/i40e_virtchnl_pf.c| 27 +--
9 files changed, 105 insertions(+), 224 deletions(-)
diff --git a/drivers/net/ethernet/intel/Kconfig
b/drivers/net/ethernet/intel/Kconfig
index bf9408a2606a..fe3c414601b0 100644
--- a/drivers/net/ethernet/intel/Kconfig
+++ b/drivers/net/ethernet/intel/Kconfig
@@ -231,6 +231,7 @@ config I40E
depends on PCI
select AUXILIARY_BUS
select LIBIE
+ select LIBIE_ADMINQ
select NET_DEVLINK
help
This driver supports Intel(R) Ethernet Controller XL710 Family of
diff --git a/drivers/net/ethernet/intel/i40e/i40e_prototype.h
b/drivers/net/ethernet/intel/i40e/i40e_prototype.h
index bd54f06b43cd..aef5de53ce3b 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_prototype.h
+++ b/drivers/net/ethernet/intel/i40e/i40e_prototype.h
@@ -46,7 +46,6 @@ void i40e_debug_aq(struct i40e_hw *hw, enum i40e_debug_mask
mask,
bool i40e_check_asq_alive(struct i40e_hw *hw);
int i40e_aq_queue_shutdown(struct i40e_hw *hw, bool unloading);
-const char *i40e_aq_str(struct i40e_hw *hw, enum libie_aq_err aq_err);
int i40e_aq_get_rss_lut(struct i40e_hw *hw, u16 seid,
bool pf_lut, u8 *lut, u16 lut_size);
diff --git a/drivers/net/ethernet/intel/i40e/i40e_client.c
b/drivers/net/ethernet/intel/i40e/i40e_client.c
index 59263551c383..5f1a405cbbf8 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_client.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_client.c
@@ -682,9 +682,7 @@ static int i40e_client_update_vsi_ctxt(struct i40e_info
*ldev,
if (err) {
dev_info(&pf->pdev->dev,
"couldn't get PF vsi config, err %pe aq_err %s\n",
-ERR_PTR(err),
-i40e_aq_str(&pf->hw,
-pf->hw.aq.asq_last_status));
+ERR_PTR(err), libie_aq_str(pf->hw.aq.asq_last_status));
return -ENOENT;
}
@@ -711,8 +709,7 @@ static int i40e_client_update_vsi_ctxt(struct i40e_info
*ldev,
dev_info(&pf->pdev->dev,
"update VSI ctxt for PE failed, err %pe aq_err
%s\n",
ERR_PTR(err),
-i40e_aq_str(&pf->hw,
-pf->hw.aq.asq_last_status));
+libie_aq_str(pf->hw.aq.asq_last_status));
}
}
return err;
diff --git a/drivers/net/ethernet/intel/i40e/i40e_common.c
b/drivers/net/ethernet/intel/i40e/i40e_common.c
index a0faa84a9e5a..ab97363fa422 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_common.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_common.c
@@ -68,58 +68,6 @@ int i40e_set_mac_type(struct i40e_hw *hw)
return status;
}
-/**
- * i40e_aq_str - convert AQ err code to a string
- * @hw: pointer to the HW structure
- * @aq_err: the AQ error code to convert
- **/
-const char *i40e_aq_str(struct i40e_hw *hw, enum libie_aq_err aq_err)
-{
- switch (aq_err) {
- case LIBIE_AQ_RC_OK:
- return "OK";
- case LIBIE_AQ_RC_EPERM:
- return "LIBIE_AQ_RC_EPERM";
- case LIBIE_AQ_RC_ENOENT:
- return "LIBIE_AQ_RC_ENOENT";
- case LIBIE_AQ_RC_ESRCH:
- return "LIBIE_AQ_RC_ESRCH";
- case LIBIE_AQ_RC_EIO:
- return "LIBIE_AQ_RC_EIO";
- case LIBIE_AQ_RC_EAGAIN:
- return "LIBIE_AQ_RC_EAGAIN";
- case LIBIE_AQ_RC_ENOMEM:
- return "LIBIE_AQ_RC_ENOMEM";
- case LIBIE_AQ_RC_EACCES:
- return "LIBIE_AQ_RC_EACCES";
- case LIBIE_AQ_RC_EBUSY:
- return "LIBIE_AQ_RC_EBUSY";
- case LIBIE_AQ_RC_EEXIST:
- return "LIBIE_AQ_RC_EEXIST";
- case LIBIE_AQ_RC_EINVAL:
- return "LIBIE_AQ_RC_EINVAL";
- case LIBIE_AQ_RC_ENOSPC:
- return "LIBIE_AQ_RC_ENOSPC";
- case LIBIE_AQ_RC_ENOSYS:
- return "LIBIE_AQ_RC_ENOSYS";
- case LIBIE_AQ_RC_EMODE:
- retu
[Intel-wired-lan] [iwl-next v1 5/8] libie: add adminq helper for converting err to str
Add a new module for common handling of Admin Queue related logic.
Start by a helper for error to string conversion. This lives inside
libie/, but is a separate module what follows our logic of splitting
into topical modules, to avoid pulling in not needed stuff, and have
better organization in general.
Olek suggested how to better solve the error to string conversion.
It will be used in follow-up patches in ice, i40e and iavf.
Reviewed-by: Przemek Kitszel
Suggested-by: Alexander Lobakin
Signed-off-by: Michal Swiatkowski
---
drivers/net/ethernet/intel/libie/Kconfig | 6 +++
drivers/net/ethernet/intel/libie/Makefile | 4 ++
include/linux/net/intel/libie/adminq.h| 2 +
drivers/net/ethernet/intel/libie/adminq.c | 50 +++
4 files changed, 62 insertions(+)
create mode 100644 drivers/net/ethernet/intel/libie/adminq.c
diff --git a/drivers/net/ethernet/intel/libie/Kconfig
b/drivers/net/ethernet/intel/libie/Kconfig
index 33aff6bc8f81..e6072758e3d8 100644
--- a/drivers/net/ethernet/intel/libie/Kconfig
+++ b/drivers/net/ethernet/intel/libie/Kconfig
@@ -8,3 +8,9 @@ config LIBIE
libie (Intel Ethernet library) is a common library built on top of
libeth and containing vendor-specific routines shared between several
Intel Ethernet drivers.
+
+config LIBIE_ADMINQ
+ tristate
+ help
+ Helper functions used by Intel Ethernet drivers for administration
+ queue command interface (aka adminq).
diff --git a/drivers/net/ethernet/intel/libie/Makefile
b/drivers/net/ethernet/intel/libie/Makefile
index ffd27fab916a..e98f00b865d3 100644
--- a/drivers/net/ethernet/intel/libie/Makefile
+++ b/drivers/net/ethernet/intel/libie/Makefile
@@ -4,3 +4,7 @@
obj-$(CONFIG_LIBIE)+= libie.o
libie-y:= rx.o
+
+obj-$(CONFIG_LIBIE_ADMINQ) += libie_adminq.o
+
+libie_adminq-y := adminq.o
diff --git a/include/linux/net/intel/libie/adminq.h
b/include/linux/net/intel/libie/adminq.h
index 684cc1c76107..5e9c8fe58692 100644
--- a/include/linux/net/intel/libie/adminq.h
+++ b/include/linux/net/intel/libie/adminq.h
@@ -304,4 +304,6 @@ static inline void *libie_aq_raw(struct libie_aq_desc *desc)
return &desc->params.raw;
}
+const char *libie_aq_str(enum libie_aq_err err);
+
#endif /* __LIBIE_ADMINQ_H */
diff --git a/drivers/net/ethernet/intel/libie/adminq.c
b/drivers/net/ethernet/intel/libie/adminq.c
new file mode 100644
index ..6c95619d1f2b
--- /dev/null
+++ b/drivers/net/ethernet/intel/libie/adminq.c
@@ -0,0 +1,50 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/* Copyright (C) 2025 Intel Corporation */
+
+#include
+#include
+
+static const char * const libie_aq_str_arr[] = {
+#define LIBIE_AQ_STR(x)\
+ [LIBIE_AQ_RC_##x] = "LIBIE_AQ_RC" #x
+ LIBIE_AQ_STR(OK),
+ LIBIE_AQ_STR(EPERM),
+ LIBIE_AQ_STR(ENOENT),
+ LIBIE_AQ_STR(ESRCH),
+ LIBIE_AQ_STR(EIO),
+ LIBIE_AQ_STR(EAGAIN),
+ LIBIE_AQ_STR(ENOMEM),
+ LIBIE_AQ_STR(EACCES),
+ LIBIE_AQ_STR(EBUSY),
+ LIBIE_AQ_STR(EEXIST),
+ LIBIE_AQ_STR(EINVAL),
+ LIBIE_AQ_STR(ENOSPC),
+ LIBIE_AQ_STR(ENOSYS),
+ LIBIE_AQ_STR(EMODE),
+ LIBIE_AQ_STR(ENOSEC),
+ LIBIE_AQ_STR(EBADSIG),
+ LIBIE_AQ_STR(ESVN),
+ LIBIE_AQ_STR(EBADMAN),
+ LIBIE_AQ_STR(EBADBUF),
+#undef LIBIE_AQ_STR
+ "LIBIE_AQ_RC_UNKNOWN",
+};
+
+#define __LIBIE_AQ_STR_NUM (ARRAY_SIZE(libie_aq_str_arr) - 1)
+
+/**
+ * libie_aq_str - get error string based on aq error
+ * @err: admin queue error type
+ */
+const char *libie_aq_str(enum libie_aq_err err)
+{
+ if (err >= ARRAY_SIZE(libie_aq_str_arr) ||
+ !libie_aq_str_arr[err])
+ err = __LIBIE_AQ_STR_NUM;
+
+ return libie_aq_str_arr[err];
+}
+EXPORT_SYMBOL_NS_GPL(libie_aq_str, "LIBIE_ADMINQ");
+
+MODULE_DESCRIPTION("Intel(R) Ethernet common library - adminq helpers");
+MODULE_LICENSE("GPL");
--
2.42.0
[Intel-wired-lan] [iwl-next v1 4/8] iavf: use libie adminq descriptors
Use libie_aq_desc instead of iavf_aq_desc. Do needed changes to allow
clean build
Use libie_aq_raw() wherever it can be used.
Reviewed-by: Przemek Kitszel
Reviewed-by: Aleksandr Loktionov
Signed-off-by: Michal Swiatkowski
---
drivers/net/ethernet/intel/iavf/iavf_adminq.h | 12 +-
.../net/ethernet/intel/iavf/iavf_adminq_cmd.h | 83 +--
.../net/ethernet/intel/iavf/iavf_prototype.h | 4 +-
drivers/net/ethernet/intel/iavf/iavf_type.h | 2 +-
drivers/net/ethernet/intel/iavf/iavf_adminq.c | 62
drivers/net/ethernet/intel/iavf/iavf_common.c | 134 +-
6 files changed, 106 insertions(+), 191 deletions(-)
diff --git a/drivers/net/ethernet/intel/iavf/iavf_adminq.h
b/drivers/net/ethernet/intel/iavf/iavf_adminq.h
index 406506f64bdd..bbf5c4b3a2ae 100644
--- a/drivers/net/ethernet/intel/iavf/iavf_adminq.h
+++ b/drivers/net/ethernet/intel/iavf/iavf_adminq.h
@@ -9,7 +9,7 @@
#include "iavf_adminq_cmd.h"
#define IAVF_ADMINQ_DESC(R, i) \
- (&(((struct iavf_aq_desc *)((R).desc_buf.va))[i]))
+ (&(((struct libie_aq_desc *)((R).desc_buf.va))[i]))
#define IAVF_ADMINQ_DESC_ALIGNMENT 4096
@@ -39,7 +39,7 @@ struct iavf_asq_cmd_details {
u16 flags_dis;
bool async;
bool postpone;
- struct iavf_aq_desc *wb_desc;
+ struct libie_aq_desc *wb_desc;
};
#define IAVF_ADMINQ_DETAILS(R, i) \
@@ -47,7 +47,7 @@ struct iavf_asq_cmd_details {
/* ARQ event information */
struct iavf_arq_event_info {
- struct iavf_aq_desc desc;
+ struct libie_aq_desc desc;
u16 msg_len;
u16 buf_len;
u8 *msg_buf;
@@ -72,8 +72,8 @@ struct iavf_adminq_info {
struct mutex arq_mutex; /* Receive queue lock */
/* last status values on send and receive queues */
- enum iavf_admin_queue_err asq_last_status;
- enum iavf_admin_queue_err arq_last_status;
+ enum libie_aq_err asq_last_status;
+ enum libie_aq_err arq_last_status;
};
/**
@@ -123,6 +123,6 @@ static inline int iavf_aq_rc_to_posix(int aq_ret, int aq_rc)
#define IAVF_AQ_LARGE_BUF 512
#define IAVF_ASQ_CMD_TIMEOUT 25 /* usecs */
-void iavf_fill_default_direct_cmd_desc(struct iavf_aq_desc *desc, u16 opcode);
+void iavf_fill_default_direct_cmd_desc(struct libie_aq_desc *desc, u16 opcode);
#endif /* _IAVF_ADMINQ_H_ */
diff --git a/drivers/net/ethernet/intel/iavf/iavf_adminq_cmd.h
b/drivers/net/ethernet/intel/iavf/iavf_adminq_cmd.h
index bc512308557b..0482c9ce9b9c 100644
--- a/drivers/net/ethernet/intel/iavf/iavf_adminq_cmd.h
+++ b/drivers/net/ethernet/intel/iavf/iavf_adminq_cmd.h
@@ -4,6 +4,8 @@
#ifndef _IAVF_ADMINQ_CMD_H_
#define _IAVF_ADMINQ_CMD_H_
+#include
+
/* This header file defines the iavf Admin Queue commands and is shared between
* iavf Firmware and Software.
*
@@ -21,87 +23,6 @@
/* API version 1.7 implements additional link and PHY-specific APIs */
#define IAVF_MINOR_VER_GET_LINK_INFO_XL710 0x0007
-struct iavf_aq_desc {
- __le16 flags;
- __le16 opcode;
- __le16 datalen;
- __le16 retval;
- __le32 cookie_high;
- __le32 cookie_low;
- union {
- struct {
- __le32 param0;
- __le32 param1;
- __le32 param2;
- __le32 param3;
- } internal;
- struct {
- __le32 param0;
- __le32 param1;
- __le32 addr_high;
- __le32 addr_low;
- } external;
- u8 raw[16];
- } params;
-};
-
-/* Flags sub-structure
- * |0 |1 |2 |3 |4 |5 |6 |7 |8 |9 |10 |11 |12 |13 |14 |15 |
- * |DD |CMP|ERR|VFE| * * RESERVED * * |LB |RD |VFC|BUF|SI |EI |FE |
- */
-
-/* command flags and offsets*/
-#define IAVF_AQ_FLAG_DD_SHIFT 0
-#define IAVF_AQ_FLAG_CMP_SHIFT 1
-#define IAVF_AQ_FLAG_ERR_SHIFT 2
-#define IAVF_AQ_FLAG_VFE_SHIFT 3
-#define IAVF_AQ_FLAG_LB_SHIFT 9
-#define IAVF_AQ_FLAG_RD_SHIFT 10
-#define IAVF_AQ_FLAG_VFC_SHIFT 11
-#define IAVF_AQ_FLAG_BUF_SHIFT 12
-#define IAVF_AQ_FLAG_SI_SHIFT 13
-#define IAVF_AQ_FLAG_EI_SHIFT 14
-#define IAVF_AQ_FLAG_FE_SHIFT 15
-
-#define IAVF_AQ_FLAG_DDBIT(IAVF_AQ_FLAG_DD_SHIFT) /* 0x1*/
-#define IAVF_AQ_FLAG_CMP BIT(IAVF_AQ_FLAG_CMP_SHIFT) /* 0x2*/
-#define IAVF_AQ_FLAG_ERR BIT(IAVF_AQ_FLAG_ERR_SHIFT) /* 0x4*/
-#define IAVF_AQ_FLAG_VFE BIT(IAVF_AQ_FLAG_VFE_SHIFT) /* 0x8*/
-#define IAVF_AQ_FLAG_LBBIT(IAVF_AQ_FLAG_LB_SHIFT) /* 0x200 */
-#define IAVF_AQ_FLAG_RDBIT(IAVF_AQ_FLAG_RD_SHIFT) /* 0x400 */
-#define IAVF_AQ_FLAG_VFC BIT(IAVF_AQ_FLAG_VFC_SHIFT) /* 0x800 */
-#define IAVF_AQ_FLAG_BUF BIT(IAVF_AQ_FLAG_BUF_SHIFT) /* 0x1000 */
-#define IAVF_AQ_FLAG_SIBIT(IAVF_AQ_FLAG_SI_SHIFT) /* 0x2000 */
-#define IAVF_AQ_FLAG_EIBIT(IAVF_AQ_FLAG_EI_SHIFT) /* 0x4000 */
-#define
[Intel-wired-lan] [iwl-next v1 0/8] libie: commonize adminq structure
Hi, It is a prework to allow reusing some specific Intel code (eq. fwlog). Move common *_aq_desc structure to libie header and changing it in ice, ixgbe, i40e and iavf. Only generic adminq commands can be easily moved to common header, as rest is slightly different. Format remains the same. It will be better to correctly move it when it will be needed to commonize other part of the code. Move *_aq_str() to new libie module (libie_adminq) and use it across drivers. The functions are exactly the same in each driver. Some more adminq helpers/functions can be moved to libie_adminq when needed. Michal Swiatkowski (8): ice, libie: move generic adminq descriptors to lib ixgbe: use libie adminq descriptors i40e: use libie adminq descriptors iavf: use libie adminq descriptors libie: add adminq helper for converting err to str ice: use libie_aq_str iavf: use libie_aq_str i40e: use libie_aq_str drivers/net/ethernet/intel/Kconfig| 3 + drivers/net/ethernet/intel/libie/Kconfig | 6 + drivers/net/ethernet/intel/libie/Makefile | 4 + drivers/net/ethernet/intel/i40e/i40e_adminq.h | 12 +- .../net/ethernet/intel/i40e/i40e_adminq_cmd.h | 155 +--- .../net/ethernet/intel/i40e/i40e_prototype.h | 15 +- drivers/net/ethernet/intel/i40e/i40e_type.h | 6 +- drivers/net/ethernet/intel/iavf/iavf_adminq.h | 12 +- .../net/ethernet/intel/iavf/iavf_adminq_cmd.h | 83 +- .../net/ethernet/intel/iavf/iavf_prototype.h | 3 +- drivers/net/ethernet/intel/iavf/iavf_type.h | 2 +- drivers/net/ethernet/intel/ice/ice.h | 1 - .../net/ethernet/intel/ice/ice_adminq_cmd.h | 267 +-- drivers/net/ethernet/intel/ice/ice_common.h | 6 +- drivers/net/ethernet/intel/ice/ice_controlq.h | 8 +- drivers/net/ethernet/intel/ixgbe/ixgbe_e610.h | 12 +- .../ethernet/intel/ixgbe/ixgbe_type_e610.h| 226 +- include/linux/net/intel/libie/adminq.h| 309 drivers/net/ethernet/intel/i40e/i40e_adminq.c | 68 +- drivers/net/ethernet/intel/i40e/i40e_client.c | 7 +- drivers/net/ethernet/intel/i40e/i40e_common.c | 730 -- drivers/net/ethernet/intel/i40e/i40e_dcb.c| 10 +- drivers/net/ethernet/intel/i40e/i40e_dcb_nl.c | 8 +- .../net/ethernet/intel/i40e/i40e_debugfs.c| 46 +- .../net/ethernet/intel/i40e/i40e_ethtool.c| 36 +- drivers/net/ethernet/intel/i40e/i40e_main.c | 240 +++--- drivers/net/ethernet/intel/i40e/i40e_nvm.c| 18 +- .../ethernet/intel/i40e/i40e_virtchnl_pf.c| 27 +- drivers/net/ethernet/intel/iavf/iavf_adminq.c | 62 +- drivers/net/ethernet/intel/iavf/iavf_common.c | 110 +-- drivers/net/ethernet/intel/iavf/iavf_main.c | 5 +- .../net/ethernet/intel/iavf/iavf_virtchnl.c | 2 +- .../net/ethernet/intel/ice/devlink/devlink.c | 10 +- .../net/ethernet/intel/ice/devlink/health.c | 6 +- drivers/net/ethernet/intel/ice/ice_common.c | 376 - drivers/net/ethernet/intel/ice/ice_controlq.c | 53 +- drivers/net/ethernet/intel/ice/ice_dcb.c | 36 +- drivers/net/ethernet/intel/ice/ice_dcb_lib.c | 2 +- drivers/net/ethernet/intel/ice/ice_ddp.c | 47 +- drivers/net/ethernet/intel/ice/ice_dpll.c | 20 +- drivers/net/ethernet/intel/ice/ice_ethtool.c | 12 +- .../net/ethernet/intel/ice/ice_fw_update.c| 38 +- drivers/net/ethernet/intel/ice/ice_fwlog.c| 16 +- drivers/net/ethernet/intel/ice/ice_lag.c | 4 +- drivers/net/ethernet/intel/ice/ice_lib.c | 10 +- drivers/net/ethernet/intel/ice/ice_main.c | 63 +- drivers/net/ethernet/intel/ice/ice_nvm.c | 38 +- drivers/net/ethernet/intel/ice/ice_ptp_hw.c | 20 +- drivers/net/ethernet/intel/ice/ice_sched.c| 18 +- drivers/net/ethernet/intel/ice/ice_sriov.c| 4 +- drivers/net/ethernet/intel/ice/ice_switch.c | 55 +- drivers/net/ethernet/intel/ice/ice_vf_mbx.c | 6 +- drivers/net/ethernet/intel/ice/ice_virtchnl.c | 6 +- .../net/ethernet/intel/ice/ice_vlan_mode.c| 6 +- .../net/ethernet/intel/ice/ice_vsi_vlan_lib.c | 24 +- drivers/net/ethernet/intel/ixgbe/ixgbe_e610.c | 272 +++ .../ethernet/intel/ixgbe/ixgbe_fw_update.c| 4 +- drivers/net/ethernet/intel/libie/adminq.c | 50 ++ 58 files changed, 1567 insertions(+), 2128 deletions(-) create mode 100644 include/linux/net/intel/libie/adminq.h create mode 100644 drivers/net/ethernet/intel/libie/adminq.c -- 2.42.0
[Intel-wired-lan] [iwl-next v1 6/8] ice: use libie_aq_str
Simple:
s/ice_aq_str/libie_aq_str
Add libie_aminq module in ice Kconfig.
Reviewed-by: Przemek Kitszel
Signed-off-by: Michal Swiatkowski
---
drivers/net/ethernet/intel/Kconfig| 1 +
drivers/net/ethernet/intel/ice/ice.h | 1 -
.../net/ethernet/intel/ice/devlink/devlink.c | 10 +--
.../net/ethernet/intel/ice/devlink/health.c | 2 +-
drivers/net/ethernet/intel/ice/ice_dpll.c | 20 +++---
drivers/net/ethernet/intel/ice/ice_ethtool.c | 12 ++--
.../net/ethernet/intel/ice/ice_fw_update.c| 20 +++---
drivers/net/ethernet/intel/ice/ice_lib.c | 4 +-
drivers/net/ethernet/intel/ice/ice_main.c | 61 +++
drivers/net/ethernet/intel/ice/ice_virtchnl.c | 4 +-
.../net/ethernet/intel/ice/ice_vsi_vlan_lib.c | 24
11 files changed, 59 insertions(+), 100 deletions(-)
diff --git a/drivers/net/ethernet/intel/Kconfig
b/drivers/net/ethernet/intel/Kconfig
index b2adb40a5921..a8fa67fe9336 100644
--- a/drivers/net/ethernet/intel/Kconfig
+++ b/drivers/net/ethernet/intel/Kconfig
@@ -294,6 +294,7 @@ config ICE
select AUXILIARY_BUS
select DIMLIB
select LIBIE
+ select LIBIE_ADMINQ
select NET_DEVLINK
select PACKING
select PLDMFW
diff --git a/drivers/net/ethernet/intel/ice/ice.h
b/drivers/net/ethernet/intel/ice/ice.h
index be4587893850..230b40a5692e 100644
--- a/drivers/net/ethernet/intel/ice/ice.h
+++ b/drivers/net/ethernet/intel/ice/ice.h
@@ -964,7 +964,6 @@ int ice_plug_aux_dev(struct ice_pf *pf);
void ice_unplug_aux_dev(struct ice_pf *pf);
int ice_init_rdma(struct ice_pf *pf);
void ice_deinit_rdma(struct ice_pf *pf);
-const char *ice_aq_str(enum libie_aq_err aq_err);
bool ice_is_wol_supported(struct ice_hw *hw);
void ice_fdir_del_all_fltrs(struct ice_vsi *vsi);
int
diff --git a/drivers/net/ethernet/intel/ice/devlink/devlink.c
b/drivers/net/ethernet/intel/ice/devlink/devlink.c
index fcb199efbea5..ca24714c8131 100644
--- a/drivers/net/ethernet/intel/ice/devlink/devlink.c
+++ b/drivers/net/ethernet/intel/ice/devlink/devlink.c
@@ -293,7 +293,7 @@ static int ice_devlink_info_get(struct devlink *devlink,
err = ice_discover_dev_caps(hw, &ctx->dev_caps);
if (err) {
dev_dbg(dev, "Failed to discover device capabilities, status %d
aq_err %s\n",
- err, ice_aq_str(hw->adminq.sq_last_status));
+ err, libie_aq_str(hw->adminq.sq_last_status));
NL_SET_ERR_MSG_MOD(extack, "Unable to discover device
capabilities");
goto out_free_ctx;
}
@@ -302,7 +302,7 @@ static int ice_devlink_info_get(struct devlink *devlink,
err = ice_get_inactive_orom_ver(hw, &ctx->pending_orom);
if (err) {
dev_dbg(dev, "Unable to read inactive Option ROM
version data, status %d aq_err %s\n",
- err, ice_aq_str(hw->adminq.sq_last_status));
+ err, libie_aq_str(hw->adminq.sq_last_status));
/* disable display of pending Option ROM */
ctx->dev_caps.common_cap.nvm_update_pending_orom =
false;
@@ -313,7 +313,7 @@ static int ice_devlink_info_get(struct devlink *devlink,
err = ice_get_inactive_nvm_ver(hw, &ctx->pending_nvm);
if (err) {
dev_dbg(dev, "Unable to read inactive NVM version data,
status %d aq_err %s\n",
- err, ice_aq_str(hw->adminq.sq_last_status));
+ err, libie_aq_str(hw->adminq.sq_last_status));
/* disable display of pending Option ROM */
ctx->dev_caps.common_cap.nvm_update_pending_nvm = false;
@@ -324,7 +324,7 @@ static int ice_devlink_info_get(struct devlink *devlink,
err = ice_get_inactive_netlist_ver(hw, &ctx->pending_netlist);
if (err) {
dev_dbg(dev, "Unable to read inactive Netlist version
data, status %d aq_err %s\n",
- err, ice_aq_str(hw->adminq.sq_last_status));
+ err, libie_aq_str(hw->adminq.sq_last_status));
/* disable display of pending Option ROM */
ctx->dev_caps.common_cap.nvm_update_pending_netlist =
false;
@@ -440,7 +440,7 @@ ice_devlink_reload_empr_start(struct ice_pf *pf,
err = ice_aq_nvm_update_empr(hw);
if (err) {
dev_err(dev, "Failed to trigger EMP device reset to reload
firmware, err %d aq_err %s\n",
- err, ice_aq_str(hw->adminq.sq_last_status));
+ err, libie_aq_str(hw->adminq.sq_last_status));
NL_SET_ERR_MSG_MOD(extack, "Failed to trigger EMP device reset
to reload firmware");
return err;
}
diff --git a/drivers/net/ethernet/intel/ice/devlink/health.c
b/drivers/net/ethernet/intel/ice/devlink/he
Re: [Intel-wired-lan] [PATCH iwl-next v6 04/15] ixgbe: add handler for devlink .info_get()
> -Original Message- > From: Intel-wired-lan On Behalf Of > Jedrzej Jagielski > Sent: Friday, March 7, 2025 7:54 PM > To: intel-wired-...@lists.osuosl.org > Cc: Nguyen, Anthony L ; > net...@vger.kernel.org; ho...@kernel.org; j...@nvidia.com; Jagielski, Jedrzej > ; Polchlopek, Mateusz > > Subject: [Intel-wired-lan] [PATCH iwl-next v6 04/15] ixgbe: add handler for > devlink .info_get() > > Provide devlink .info_get() callback implementation to allow the driver to > report detailed version information. The following info is reported: > > "serial_number" -> The PCI DSN of the adapter "fw.bundle_id" -> Unique > identifier for the combined flash image "fw.undi" -> Version of the Option > ROM containing the UEFI driver "board.id" -> The PBA ID string > > Reviewed-by: Mateusz Polchlopek > Signed-off-by: Jedrzej Jagielski > --- > v2: zero the ctx buff when chance it won't be filled out > v4: use devlink_priv() > v6: fix devlink_*_put() labels > --- > Documentation/networking/devlink/ixgbe.rst| 32 ++ > .../ethernet/intel/ixgbe/devlink/devlink.c| 101 ++ > 2 files changed, 133 insertions(+) > Tested-by: Bharath R
Re: [Intel-wired-lan] [PATCH iwl-next v6 08/15] ixgbe: add .info_get extension specific for E610 devices
> -Original Message- > From: Intel-wired-lan On Behalf Of > Jedrzej Jagielski > Sent: Friday, March 7, 2025 7:54 PM > To: intel-wired-...@lists.osuosl.org > Cc: Nguyen, Anthony L ; > net...@vger.kernel.org; ho...@kernel.org; j...@nvidia.com; Jagielski, Jedrzej > ; Polchlopek, Mateusz > ; Mrozowicz, SlawomirX > ; Kwapulinski, Piotr > > Subject: [Intel-wired-lan] [PATCH iwl-next v6 08/15] ixgbe: add .info_get > extension specific for E610 devices > > E610 devices give possibility to show more detailed info than the previous > boards. > Extend reporting NVM info with following pieces: > fw.mgmt.api -> version number of the API fw.mgmt.build -> identifier of the > source for the FW fw.psid.api -> version defining the format of the flash > contents fw.netlist -> version of the netlist module fw.netlist.build -> > first 4 > bytes of the netlist hash > > Reviewed-by: Mateusz Polchlopek > Co-developed-by: Slawomir Mrozowicz > Signed-off-by: Slawomir Mrozowicz > Co-developed-by: Piotr Kwapulinski > Signed-off-by: Piotr Kwapulinski > Signed-off-by: Jedrzej Jagielski > --- > Documentation/networking/devlink/ixgbe.rst| 26 > .../ethernet/intel/ixgbe/devlink/devlink.c| 132 +- > 2 files changed, 153 insertions(+), 5 deletions(-) > Tested-by: Bharath R
Re: [Intel-wired-lan] [PATCH iwl-next v6 10/15] ixgbe: extend .info_get with stored versions
> -Original Message- > From: Intel-wired-lan On Behalf Of > Jedrzej Jagielski > Sent: Friday, March 7, 2025 7:54 PM > To: intel-wired-...@lists.osuosl.org > Cc: Nguyen, Anthony L ; > net...@vger.kernel.org; ho...@kernel.org; j...@nvidia.com; Jagielski, Jedrzej > ; Polchlopek, Mateusz > ; Kitszel, Przemyslaw > ; Mrozowicz, SlawomirX > ; Kwapulinski, Piotr > > Subject: [Intel-wired-lan] [PATCH iwl-next v6 10/15] ixgbe: extend .info_get > with stored versions > > Add functions reading inactive versions from the inactive flash banks. > > Print stored NVM, OROM and netlist versions by devlink when there is an > ongoing update for E610 devices. > > Reviewed-by: Mateusz Polchlopek > Reviewed-by: Przemek Kitszel > Co-developed-by: Slawomir Mrozowicz > Signed-off-by: Slawomir Mrozowicz > Co-developed-by: Piotr Kwapulinski > Signed-off-by: Piotr Kwapulinski > Signed-off-by: Jedrzej Jagielski > --- > v3: use devlink_info_version_*_put() function; squash functions dealing with > running and stored versions into single ones > v5: add else to if/else if statements > --- > .../ethernet/intel/ixgbe/devlink/devlink.c| 214 -- > drivers/net/ethernet/intel/ixgbe/ixgbe_e610.c | 59 + > drivers/net/ethernet/intel/ixgbe/ixgbe_e610.h | 3 + > 3 files changed, 252 insertions(+), 24 deletions(-) > Tested-by: Bharath R
[Intel-wired-lan] [PATCH iwl-next v2] ice: add E830 Earliest TxTime First Offload support
E830 supports Earliest TxTime First (ETF) hardware offload, which is
configured via the ETF Qdisc (see tc-etf(8)). ETF introduces a new Tx flow
mechanism that utilizes a timestamp ring (tstamp_ring) alongside the
standard Tx ring. This timestamp ring is used to indicate when hardware
will transmit a packet.
The allocation and initialization of the timestamp ring occur when the
feature is enabled via tc-etf. Since the timestamp ring and Tx ring are
tightly coupled, both must be configured simultaneously.
To support ETF, the following flags are introduced:
- ICE_F_TXTIME: Device feature flag set for E830 NICs, indicating ETF
support.
- ICE_FLAG_TXTIME: PF-level flag indicating whether ETF is enabled on any
Tx queue. It is checked during ring allocation to determine if timestamp
rings should be allocated and is also referenced when modifying queue
count via ethtool -G.
- ICE_TX_FLAGS_TXTIME: Per-ring flag set when ETF is enabled and cleared
when disabled for a specific Tx queue. It helps determine ETF status
when transmitting timestamped packets and is used by ice_is_txtime_ena()
to check if ETF is enabled on any Tx queue.
Due to a hardware issue that can result in a malicious driver detection
event, additional timestamp descriptors are required when wrapping the
timestamp ring. Up to 64 additional timestamp descriptors are reserved,
reducing the available Tx descriptors.
To accommodate this, ICE_MAX_NUM_DESC_BY_MAC is introduced, defining:
- E830: Maximum Tx descriptor length of 8096 (8K - 32 - 64 for timestamp
fetch descriptors).
- E810 and E82X: Maximum Tx descriptor length of 8160 (8K - 32) .
Reviewed-by: Aleksandr Loktionov
Co-developed-by: Alice Michael
Signed-off-by: Alice Michael
Signed-off-by: Paul Greenwalt
---
Changelog:
v0->v1:
- Resolve patch apply isue.
- Fixes RCT, zero struct initialization, move bailout condition to top
of function, removed unnecessary newlines, and added use of
str_enable_disable.
v0:
https://patchwork.ozlabs.org/project/intel-wired-lan/patch/20250227111333.30675-1-paul.greenw...@intel.com/
---
drivers/net/ethernet/intel/ice/ice.h | 9 +-
.../net/ethernet/intel/ice/ice_adminq_cmd.h | 53 +
drivers/net/ethernet/intel/ice/ice_base.c | 210 +++---
drivers/net/ethernet/intel/ice/ice_base.h | 1 +
drivers/net/ethernet/intel/ice/ice_common.c | 118 ++
drivers/net/ethernet/intel/ice/ice_common.h | 10 +
drivers/net/ethernet/intel/ice/ice_ethtool.c | 61 -
.../net/ethernet/intel/ice/ice_hw_autogen.h | 3 +
.../net/ethernet/intel/ice/ice_lan_tx_rx.h| 42
drivers/net/ethernet/intel/ice/ice_lib.c | 45 +++-
drivers/net/ethernet/intel/ice/ice_main.c | 174 ++-
drivers/net/ethernet/intel/ice/ice_txrx.c | 129 ++-
drivers/net/ethernet/intel/ice/ice_txrx.h | 4 +
drivers/net/ethernet/intel/ice/ice_txrx_lib.h | 14 ++
drivers/net/ethernet/intel/ice/ice_virtchnl.c | 2 +-
15 files changed, 822 insertions(+), 53 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice.h
b/drivers/net/ethernet/intel/ice/ice.h
index 2694951a0b1d..43a34e3fa762 100644
--- a/drivers/net/ethernet/intel/ice/ice.h
+++ b/drivers/net/ethernet/intel/ice/ice.h
@@ -83,7 +83,11 @@
#define ICE_BAR0 0
#define ICE_REQ_DESC_MULTIPLE 32
#define ICE_MIN_NUM_DESC 64
-#define ICE_MAX_NUM_DESC 8160
+#define ICE_MAX_NUM_DESC_E810 8160
+#define ICE_MAX_NUM_DESC_E830 8096
+#define ICE_MAX_NUM_DESC_BY_MAC(hw) ((hw)->mac_type == ICE_MAC_E830 ? \
+ICE_MAX_NUM_DESC_E830 : \
+ICE_MAX_NUM_DESC_E810)
#define ICE_DFLT_MIN_RX_DESC 512
#define ICE_DFLT_NUM_TX_DESC 256
#define ICE_DFLT_NUM_RX_DESC 2048
@@ -201,6 +205,7 @@ enum ice_feature {
ICE_F_SMA_CTRL,
ICE_F_CGU,
ICE_F_GNSS,
+ ICE_F_TXTIME,
ICE_F_GCS,
ICE_F_ROCE_LAG,
ICE_F_SRIOV_LAG,
@@ -332,6 +337,7 @@ struct ice_vsi {
struct ice_pf *back; /* back pointer to PF */
struct ice_rx_ring **rx_rings; /* Rx ring array */
struct ice_tx_ring **tx_rings; /* Tx ring array */
+ struct ice_tx_ring **tstamp_rings; /* Time stamp ring array */
struct ice_q_vector **q_vectors; /* q_vector array */
irqreturn_t (*irq_handler)(int irq, void *data);
@@ -516,6 +522,7 @@ enum ice_pf_flags {
ICE_FLAG_GNSS, /* GNSS successfully initialized */
ICE_FLAG_DPLL, /* SyncE/PTP dplls initialized */
ICE_FLAG_LLDP_AQ_FLTR,
+ ICE_FLAG_TXTIME,
ICE_PF_FLAGS_NBITS /* must be last */
};
diff --git a/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h
b/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h
index bdee499f991a..2eaa4ab8e791 100644
--- a/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h
+++ b/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h
@@ -15
Re: [Intel-wired-lan] [PATCH iwl-next v2] ice: add E830 Earliest TxTime First Offload support
Hi Paul,
kernel test robot noticed the following build errors:
[auto build test ERROR on tnguy-next-queue/dev-queue]
url:
https://github.com/intel-lab-lkp/linux/commits/Paul-Greenwalt/ice-add-E830-Earliest-TxTime-First-Offload-support/20250312-051400
base: https://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue.git
dev-queue
patch link:
https://lore.kernel.org/r/20250311132327.76804-1-paul.greenwalt%40intel.com
patch subject: [PATCH iwl-next v2] ice: add E830 Earliest TxTime First Offload
support
config: arm-randconfig-003-20250312
(https://download.01.org/0day-ci/archive/20250312/202503121018.cugx8ufd-...@intel.com/config)
compiler: clang version 19.1.7 (https://github.com/llvm/llvm-project
cd708029e0b2869e80abe31ddb175f7c35361f90)
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20250312/202503121018.cugx8ufd-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202503121018.cugx8ufd-...@intel.com/
All errors (new ones prefixed by >>):
>> drivers/net/ethernet/intel/ice/ice_base.c:1023:39: error: passing 'const
>> struct ice_vsi *' to parameter of type 'struct ice_vsi *' discards
>> qualifiers [-Werror,-Wincompatible-pointer-types-discards-qualifiers]
1023 | ring->q_handle = ice_calc_txq_handle(vsi, ring, tc);
| ^~~
drivers/net/ethernet/intel/ice/ice_base.c:245:48: note: passing argument to
parameter 'vsi' here
245 | static u16 ice_calc_txq_handle(struct ice_vsi *vsi, struct
ice_tx_ring *ring, u8 tc)
|^
1 error generated.
vim +1023 drivers/net/ethernet/intel/ice/ice_base.c
eff380aaffedb27 Anirudh Venkataramanan 2019-10-24 974
eff380aaffedb27 Anirudh Venkataramanan 2019-10-24 975 /**
eff380aaffedb27 Anirudh Venkataramanan 2019-10-24 976 * ice_vsi_cfg_txq -
Configure single Tx queue
eff380aaffedb27 Anirudh Venkataramanan 2019-10-24 977 * @vsi: the VSI that
queue belongs to
eff380aaffedb27 Anirudh Venkataramanan 2019-10-24 978 * @ring: Tx ring to
be configured
51900dfcf194b39 Paul Greenwalt 2025-03-11 979 * @tstamp_ring: time
stamp ring to be configured
eff380aaffedb27 Anirudh Venkataramanan 2019-10-24 980 * @qg_buf: queue
group buffer
51900dfcf194b39 Paul Greenwalt 2025-03-11 981 * @txtime_qg_buf: Tx
Time queue group buffer
51900dfcf194b39 Paul Greenwalt 2025-03-11 982 *
51900dfcf194b39 Paul Greenwalt 2025-03-11 983 * Return: 0 on
success and a negative value on error.
eff380aaffedb27 Anirudh Venkataramanan 2019-10-24 984 */
a292ba981324ec7 Maciej Fijalkowski 2024-01-23 985 static int
51900dfcf194b39 Paul Greenwalt 2025-03-11 986 ice_vsi_cfg_txq(const
struct ice_vsi *vsi, struct ice_tx_ring *ring,
51900dfcf194b39 Paul Greenwalt 2025-03-11 987 struct
ice_tx_ring *tstamp_ring,
51900dfcf194b39 Paul Greenwalt 2025-03-11 988 struct
ice_aqc_add_tx_qgrp *qg_buf,
51900dfcf194b39 Paul Greenwalt 2025-03-11 989 struct
ice_aqc_set_txtime_qgrp *txtime_qg_buf)
eff380aaffedb27 Anirudh Venkataramanan 2019-10-24 990 {
66486d8943bac36 Bruce Allan2020-06-29 991 u8 buf_len =
struct_size(qg_buf, txqs, 1);
eff380aaffedb27 Anirudh Venkataramanan 2019-10-24 992 struct
ice_tlan_ctx tlan_ctx = { 0 };
eff380aaffedb27 Anirudh Venkataramanan 2019-10-24 993 struct
ice_aqc_add_txqs_perq *txq;
0754d65bd4be5bb Kiran Patil2021-10-15 994 struct
ice_channel *ch = ring->ch;
eff380aaffedb27 Anirudh Venkataramanan 2019-10-24 995 struct ice_pf
*pf = vsi->back;
7e34786a74e1403 Bruce Allan2020-05-15 996 struct ice_hw
*hw = &pf->hw;
5e24d5984c805c6 Tony Nguyen2021-10-07 997 int status;
eff380aaffedb27 Anirudh Venkataramanan 2019-10-24 998 u16 pf_q;
e75d1b2c3731999 Maciej Fijalkowski 2019-10-24 999 u8 tc;
eff380aaffedb27 Anirudh Venkataramanan 2019-10-24 1000
634da4c118434cf Benita Bose2021-03-02 1001 /* Configure
XPS */
634da4c118434cf Benita Bose2021-03-02 1002
ice_cfg_xps_tx_ring(ring);
634da4c118434cf Benita Bose2021-03-02 1003
eff380aaffedb27 Anirudh Venkataramanan 2019-10-24 1004 pf_q =
ring->reg_idx;
eff380aaffedb27 Anirudh Venkataramanan 2019-10-24 1005
ice_setup_tx_ctx(ring, &tlan_ctx, pf_q);
eff380aaffedb27 Anirudh Venkataramanan 2019-10-24 1006 /* copy context
contents into the qg_buf */
eff380aaffedb27 Anirudh Venkataramanan 2019-10-24 1007
qg_buf->txqs[0].txq_id = cpu_to_le16(pf_q);
dc4305be467a6f8 Jacob Keller 2024-12-10 1008
Re: [Intel-wired-lan] [PATCH iwl-next] ice: use DSN instead of PCI BDF for ice_adapter index
-void ice_adapter_put(const struct pci_dev *pdev)
+void ice_adapter_put(struct pci_dev *pdev)
{
A bit of a shame that this needs to be non const now.. Could
pci_get_dsn() be made const? Or does it do something which might modify
the device somehow?
Would make sense to me to make it const.
It would indeed, but to do so, one have to constify at least a few other
pci_* functions, I didn't even got to the bottom.
While I appreciate the added value of typechecks, I would like to focus
on different work, especially that there are contributors that seems to
be focused on the hunt of such cases :)
unsigned long index = ice_adapter_index(pdev);
struct ice_adapter *adapter;
[Intel-wired-lan] [tnguy-next-queue:100GbE] BUILD SUCCESS 4f262e9f14eb198ecef69562d87b02a766b772a0
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue.git 100GbE branch HEAD: 4f262e9f14eb198ecef69562d87b02a766b772a0 ixgbe: add support for thermal sensor event reception elapsed time: 1460m configs tested: 106 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: alpha allnoconfiggcc-14.2.0 alphaallyesconfiggcc-14.2.0 arc allmodconfiggcc-13.2.0 arc allnoconfiggcc-13.2.0 arc allyesconfiggcc-13.2.0 arc randconfig-001-20250311gcc-13.2.0 arc randconfig-002-20250311gcc-13.2.0 arm allmodconfiggcc-14.2.0 arm allnoconfigclang-17 arm allyesconfiggcc-14.2.0 arm randconfig-001-20250311gcc-14.2.0 arm randconfig-002-20250311clang-16 arm randconfig-003-20250311gcc-14.2.0 arm randconfig-004-20250311gcc-14.2.0 arm64allmodconfigclang-18 arm64 allnoconfiggcc-14.2.0 arm64 randconfig-001-20250311gcc-14.2.0 arm64 randconfig-002-20250311gcc-14.2.0 arm64 randconfig-003-20250311gcc-14.2.0 arm64 randconfig-004-20250311gcc-14.2.0 csky allnoconfiggcc-14.2.0 csky randconfig-001-20250311gcc-14.2.0 csky randconfig-002-20250311gcc-14.2.0 hexagon allmodconfigclang-21 hexagon allnoconfigclang-21 hexagon allyesconfigclang-18 hexagon randconfig-001-20250311clang-21 hexagon randconfig-002-20250311clang-21 i386 allnoconfiggcc-12 i386 allyesconfiggcc-12 i386buildonly-randconfig-001-20250311gcc-12 i386buildonly-randconfig-001-20250312gcc-12 i386buildonly-randconfig-002-20250311clang-19 i386buildonly-randconfig-002-20250312gcc-12 i386buildonly-randconfig-003-20250311clang-19 i386buildonly-randconfig-003-20250312gcc-12 i386buildonly-randconfig-004-20250311clang-19 i386buildonly-randconfig-004-20250312gcc-12 i386buildonly-randconfig-005-20250311clang-19 i386buildonly-randconfig-005-20250312gcc-12 i386buildonly-randconfig-006-20250311gcc-11 i386buildonly-randconfig-006-20250312gcc-12 i386defconfigclang-19 loongarchallmodconfiggcc-14.2.0 loongarch allnoconfiggcc-14.2.0 loongarch randconfig-001-20250311gcc-14.2.0 loongarch randconfig-002-20250311gcc-14.2.0 m68k allmodconfiggcc-14.2.0 m68k allnoconfiggcc-14.2.0 m68k allyesconfiggcc-14.2.0 microblazeallnoconfiggcc-14.2.0 mips allnoconfiggcc-14.2.0 nios2 allnoconfiggcc-14.2.0 nios2 randconfig-001-20250311gcc-14.2.0 nios2 randconfig-002-20250311gcc-14.2.0 openrisc allnoconfiggcc-14.2.0 openrisc allyesconfiggcc-14.2.0 parisc allmodconfiggcc-14.2.0 pariscallnoconfiggcc-14.2.0 parisc allyesconfiggcc-14.2.0 pariscrandconfig-001-20250311gcc-14.2.0 pariscrandconfig-002-20250311gcc-14.2.0 powerpc allmodconfiggcc-14.2.0 powerpc allnoconfiggcc-14.2.0 powerpc randconfig-001-20250311clang-21 powerpc randconfig-002-20250311clang-16 powerpc randconfig-003-20250311gcc-14.2.0 powerpc64 randconfig-001-20250311gcc-14.2.0 powerpc64 randconfig-002-20250311clang-18 powerpc64 randconfig-003-20250311gcc-14.2.0 riscv allnoconfiggcc-14.2.0 riscv randconfig-001-20250311gcc-14.2.0 riscv randconfig-002-20250311gcc-14.2.0 s390 allmodconfigclang-19 s390 allnoconfigclang-15 s390 allyesconfiggcc-14.2.0 s390 randconfig-001-20250311clang-15 s390 randconfig-002-20250311gcc-14.2.0 sh
