On 9/4/24 14:00, Michal Swiatkowski wrote:
First case:
[...]
Second case:
[...]
With fix for previous case we end up with no VLAN filters in hardware.
We have to remove VLAN filters if the state is IAVF_VLAN_ADD and delete
VLAN was called. It is save as IAVF_VLAN_ADD means that virtchnl m
On 9/3/2024 8:29 PM, Greenwalt, Paul wrote:
>>>
>>> @@ -6237,6 +6243,7 @@ ice_fix_features(struct net_device *netdev,
>>> netdev_features_t features)
>>> struct ice_netdev_priv *np = netdev_priv(netdev);
>>> netdev_features_t req_vlan_fltr, cur_vlan_fltr;
>>> bool cur_ctag, cur_s
On Wed, 4 Sep 2024 15:53:46 +0200 Paolo Abeni wrote:
> +static int iavf_verify_handle(struct net_shaper_binding *binding,
> + const struct net_shaper_handle *handle,
> + struct netlink_ext_ack *extack)
> +{
> + struct iavf_adapter *adapter =
On Wed, 4 Sep 2024 15:53:42 +0200 Paolo Abeni wrote:
> Use the device capabilities to reject invalid attribute values before
> pushing them to the H/W.
>
> Note that validating the metric explicitly avoids NL_SET_BAD_ATTR()
> usage, to provide unambiguous error messages to the user.
>
> Validati
On Wed, 4 Sep 2024 15:53:39 +0200 Paolo Abeni wrote:
> + net_shaper_set_real_num_tx_queues(dev, txq);
> +
> dev_qdisc_change_real_num_tx(dev, txq);
>
> dev->real_num_tx_queues = txq;
The dev->lock has to be taken here, around those three lines,
and then s
On Wed, 4 Sep 2024 15:53:34 +0200 Paolo Abeni wrote:
> +doc: |
> + Networking HW rate limiting configuration.
> +
> + This API allows configuring HW shapers available on the network
> + devices at different levels (queues, network device) and allows
> + arbitrary manipulation of the scheduling
On Wed, 4 Sep 2024 15:53:35 +0200 Paolo Abeni wrote:
> +static int net_shaper_ctx_setup(const struct genl_info *info, int type,
> + struct net_shaper_nl_ctx *ctx)
> +{
> + struct net *ns = genl_info_net(info);
> + struct net_device *dev;
> + int ifindex;
> +
On Wed, 4 Sep 2024 15:53:33 +0200 Paolo Abeni wrote:
> This allows a more uniform implementation of non-dump and dump
> operations, and will be used later in the series to avoid some
> per-operation allocation.
>
> Additionally rename the NL_ASSERT_DUMP_CTX_FITS macro, to
> fit a more extended us
On Wed, Sep 04, 2024 at 09:00:32PM +, Loktionov, Aleksandr wrote:
>
>
> > -Original Message-
> > From: Intel-wired-lan On Behalf
> > Of YangHang Liu
> > Sent: Wednesday, September 4, 2024 4:37 AM
> > To: Kamal Heib ; Chao Yang
> > Cc: ivecera ; net...@vger.kernel.org; Jakub
> > Kici
buildonly-randconfig-001-20240904 clang-18
x86_64 buildonly-randconfig-002-20240904 clang-18
x86_64 buildonly-randconfig-003-20240904 clang-18
x86_64 buildonly-randconfig-004-20240904 clang-18
x86_64 buildonly-randconfig-005-20240904 clang-18
x86_64 buildonly
> -Original Message-
> From: Intel-wired-lan On Behalf
> Of YangHang Liu
> Sent: Wednesday, September 4, 2024 4:37 AM
> To: Kamal Heib ; Chao Yang
> Cc: ivecera ; net...@vger.kernel.org; Jakub
> Kicinski ; Nguyen, Anthony L
> ; Kitszel, Przemyslaw
> ; intel-wired-...@lists.osuosl.org;
>
On 9/4/2024 5:32 AM, Przemek Kitszel wrote:
> dev = ice_pf_to_dev(pf);
> - /* ice_cfg_tx_topo buf argument is not a constant,
> - * so we have to make a copy
> - */
> - buf_copy = kmemdup(firmware->data, firmware->size, GFP_KERNEL);
> -
> - err = ice_cfg_tx_topo(hw, b
On 02.09.24 15:14, Hongbo Li wrote:
We have for some time the assign_bit() API to replace open coded
if (foo)
set_bit(n, bar);
else
clear_bit(n, bar);
Use this API to clean the code. No functional change intended.
Signed-off-by: Hongbo Li
---
drivers/net/
From: Joshua Hay
Tell hardware to write back completed descriptors even when interrupts
are disabled. Otherwise, descriptors might not be written back until
the hardware can flush a full cacheline of descriptors. This can cause
unnecessary delays when traffic is light (or even trigger Tx queue
ti
From: Michal Kubiak
netif_txq_maybe_stop() returns -1, 0, or 1, while
idpf_tx_maybe_stop_common() says it returns 0 or -EBUSY. As a result,
there sometimes are Tx queue timeout warnings despite that the queue
is empty or there is at least enough space to restart it.
Make idpf_tx_maybe_stop_common
From: Joshua Hay
Add a mechanism to guard against stashing partial packets into the hash
table to make the driver more robust, with more efficient decision
making when cleaning.
Don't stash partial packets. This can happen when an RE (Report Event)
completion is received in flow scheduling mode,
&idpf_tx_buffer is almost identical to the previous generations, as well
as the way it's handled. Moreover, relying on dma_unmap_addr() and
!!buf->skb instead of explicit defining of buffer's type was never good.
Use the newly added libeth helpers to do it properly and reduce the
copy-paste around
Add a shorthand similar to other net*_subqueue() helpers for resetting
the queue by its index w/o obtaining &netdev_tx_queue beforehand
manually.
Reviewed-by: Przemek Kitszel
Signed-off-by: Alexander Lobakin
---
include/linux/netdevice.h | 13 -
1 file changed, 12 insertions(+), 1 d
Software-side Tx buffers for storing DMA, frame size, skb pointers etc.
are pretty much generic and every driver defines them the same way. The
same can be said for software Tx completions -- same napi_consume_skb()s
and all that...
Add a couple simple wrappers for doing that to stop repeating the
XDP for idpf is currently 5 chapters:
* convert Rx to libeth;
* convert Tx completion to libeth (this);
* generic XDP and XSk code changes;
* actual XDP for idpf via libeth_xdp;
* XSk for idpf (^).
Part II does the following:
* adds generic libeth Tx completion routines;
* converts idpf to use gen
> My colleague, Kohei, tested the patch with a real hardware and will provide
> his
> Tested-by shortly.
I have tested the patch using my physical hardware, an Intel Ethernet
controller I219-V. The device was properly attached by the e1000e driver and
functioned correctly. The test was performe
This issue can be reproduced by hot-unplugging the INTx i40e PF.
The Call Trace will disappear after using Kamal's fix.
Tested-by: Yanghang Liu
On Wed, Sep 4, 2024 at 2:26 AM Kamal Heib wrote:
>
> Avoid the following warning when trying to free an already freed IRQ,
> The issue happens when t
allnoconfig clang-18
i386 allyesconfig clang-18
i386 buildonly-randconfig-001-20240904 gcc-12
i386 buildonly-randconfig-002-20240904 gcc-12
i386 buildonly-randconfig-003-20240904 gcc-12
i386 buildonly-randconfig-004
From: Sudheer Mogilappagari
During driver initialization VF determines QOS capability is allowed
by PF and receives QOS parameters. After which quanta size for queues
is configured which is not configurable and is set to 1KB currently.
Signed-off-by: Sudheer Mogilappagari
---
v5 -> v6:
- error
From: Sudheer Mogilappagari
Implement net_shaper_ops support for IAVF. This enables configuration
of rate limiting on per queue basis. Customer intends to enforce
bandwidth limit on Tx traffic steered to the queue by configuring
rate limits on the queue.
To set rate limiting for a queue, update
From: Wenjun Wu
Add support to configure VF queue rate limit and quanta size.
For quanta size configuration, the quanta profiles are divided evenly
by PF numbers. For each port, the first quanta profile is reserved for
default. When VF is asked to set queue quanta size, PF will search for
an ava
The netlink op is a simple wrapper around the device callback.
Extend the existing fetch_dev() helper adding an attribute argument
for the requested device. Reuse such helper in the newly implemented
operation.
Signed-off-by: Paolo Abeni
---
v5 -> v6:
- update to new API
v4 -> v5:
- replace n
From: Wenjun Wu
This patch adds new virtchnl opcodes and structures for rate limit
and quanta size configuration, which include:
1. VIRTCHNL_OP_CONFIG_QUEUE_BW, to configure max bandwidth for each
VF per queue.
2. VIRTCHNL_OP_CONFIG_QUANTA, to configure quanta size per queue.
3. VIRTCHNL_OP_GET_Q
Leverage a basic/dummy netdevsim implementation to do functional
coverage for NL interface.
Signed-off-by: Paolo Abeni
---
v5 -> v6:
- additional test-cases for delegation and queue reconf
v4 -> v5:
- updated to new driver API
- more consistent indentation
rfc v1 -> v2:
- added more tes
Use the device capabilities to reject invalid attribute values before
pushing them to the H/W.
Note that validating the metric explicitly avoids NL_SET_BAD_ATTR()
usage, to provide unambiguous error messages to the user.
Validating the nesting requires the knowledge of the new parent for
the give
Allow the user-space to fine-grain query the shaping features
supported by the NIC on each domain.
Signed-off-by: Paolo Abeni
---
v5 -> v6:
- shorter cap-related names
v4 -> v5:
- added pre/post helpers for dump op
---
Documentation/netlink/specs/net_shaper.yaml | 88 +
in
hook into netif_set_real_num_tx_queues() to cleanup any shaper
configured on top of the to-be-destroyed TX queues.
Signed-off-by: Paolo Abeni
---
net/core/dev.c | 2 ++
net/core/dev.h | 4
net/shaper/shaper.c | 31 +++
3 files changed, 37 insertions(+
Leverage the previously introduced group operation to implement
the removal of NODE scope shaper, re-linking its leaves under the
the parent node before actually deleting the specified NODE scope
shaper.
Signed-off-by: Paolo Abeni
---
v4 -> v5:
- replace net_device* with binding* in most helpers
Allow grouping multiple leaves shaper under the given root.
The node and the leaves shapers are created, if needed, otherwise
the existing shapers are re-linked as requested.
Try hard to pre-allocated the needed resources, to avoid non
trivial H/W configuration rollbacks in case of any failure.
S
Both NL operations directly map on the homonymous device shaper
callbacks, update accordingly the shapers cache and are serialized
via a per device lock.
Implement the cache modification helpers to additionally deal with
NODE scope shaper. That will be needed by the group() operation
implemented in
Introduce the basic infrastructure to implement the net-shaper
core functionality. Each network devices carries a net-shaper cache,
the NL get() operation fetches the data from such cache.
The cache is initially empty, will be fill by the set()/group()
operation implemented later and is destroyed
Define the user-space visible interface to query, configure and delete
network shapers via yaml definition.
Add dummy implementations for the relevant NL callbacks.
set() and delete() operations touch a single shaper creating/updating or
deleting it.
The group() operation creates a shaper's group
This allows a more uniform implementation of non-dump and dump
operations, and will be used later in the series to avoid some
per-operation allocation.
Additionally rename the NL_ASSERT_DUMP_CTX_FITS macro, to
fit a more extended usage.
Suggested-by: Jakub Kicinski
Signed-off-by: Paolo Abeni
--
We have a plurality of shaping-related drivers API, but none flexible
enough to meet existing demand from vendors[1].
This series introduces new device APIs to configure in a flexible way
TX H/W shaping. The new functionalities are exposed via a newly
defined generic netlink interface and include
> -Original Message-
> From: Intel-wired-lan On Behalf Of Karol
> Kolacinski
> Sent: Friday, August 30, 2024 4:37 PM
> To: intel-wired-...@lists.osuosl.org
> Cc: Temerkhanov, Sergey ;
> net...@vger.kernel.org; Kubalewski, Arkadiusz
> ; Kolacinski, Karol
> ; Nguyen, Anthony L ;
> Simon
On 9/4/24 11:31, Przemek Kitszel wrote:
Constify ice_cfg_tx_topo() @buf parameter.
This cascades further down to few more functions.
I set the boundary on ice_get_set_tx_topo(), which could not be easily
constified as it is get-or-set, but it's set variant does not change
provided data, the same
On 9/4/2024 3:13 PM, Andrew Lunn wrote:
On Wed, Sep 04, 2024 at 02:56:46PM +0900, Takamitsu Iwai wrote:
So you have confirmed with the datsheet that the write is not needed?
As i said, this is a hardware register, not memory. Writes are not
always idempotent. It might be necessary to write it
> -Original Message-
> From: Intel-wired-lan On Behalf Of
> Alexander Lobakin
> Sent: Wednesday, August 21, 2024 3:21 PM
> To: Greenwalt, Paul
> Cc: pmen...@molgen.mpg.de; intel-wired-...@lists.osuosl.org
> Subject: Re: [Intel-wired-lan] [PATCH iwl-next v5] ice: add E830 HW VF mailbox
> m
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue.git 100GbE
branch HEAD: 04c7e14e5b0b6227e7b00d7a96ca2f2426ab9171 ice: do not bring the
VSI up, if it was down before the XDP setup
elapsed time: 1038m
configs tested: 93
configs skipped: 3
The following configs have
Fix leak of the FW blob, by not copying it.
ice_cfg_tx_topo() is not changing the passed buffer, but constification
of it is not a -net material, constification patch is mentioned by Link.
This was found by kmemleak, with the following trace for each PF:
[] kmemdup_noprof+0x1d/0x50
[] ice_
On Wed, Sep 04, 2024 at 02:56:46PM +0900, Takamitsu Iwai wrote:
> > So you have confirmed with the datsheet that the write is not needed?
> >
> > As i said, this is a hardware register, not memory. Writes are not
> > always idempotent. It might be necessary to write it twice.
>
> I have checked fo
First case:
> ip l a l $VF name vlanx type vlan id 100
> ip l d vlanx
> ip l a l $VF name vlanx type vlan id 100
As workqueue can be execute after sometime, there is a window to have
call trace like that:
- iavf_del_vlan
- iavf_add_vlan
- iavf_del_vlans (wq)
It means that our VLAN 100 will change
ng-18
i386 allnoconfig clang-18
i386 allyesconfig clang-18
i386 buildonly-randconfig-001-20240904 gcc-12
i386 buildonly-randconfig-002-20240904 gcc-12
i386 buildonly-randconfig-003-20240904 gcc-12
i386 buildonly-rand
When the device is removed, idpf is supposed to make certain virtchnl
requests e.g. VIRTCHNL2_OP_DEALLOC_VECTORS and VIRTCHNL2_OP_DESTROY_VPORT.
However, this does not happen due to the referenced commit introducing
virtchnl transaction manager and placing its deinitialization before those
message
The description of function ice_find_vsi_list_entry says:
Search VSI list map with VSI count 1
However, since the blamed commit (see Fixes below), the function no
longer checks vsi_count. This causes a problem in ice_add_vlan_internal,
where the decision to share VSI lists between filter rules r
Constify ice_cfg_tx_topo() @buf parameter.
This cascades further down to few more functions.
I set the boundary on ice_get_set_tx_topo(), which could not be easily
constified as it is get-or-set, but it's set variant does not change
provided data, the same holds for ice_aqc_opc_set_tx_topo() in pa
> -Original Message-
> From: Intel-wired-lan On Behalf Of
> Sergey Temerkhanov
> Sent: Wednesday, August 21, 2024 6:40 PM
> To: intel-wired-...@lists.osuosl.org
> Cc: Temerkhanov, Sergey ;
> net...@vger.kernel.org; Simon Horman ; Kitszel, Przemyslaw
>
> Subject: [Intel-wired-lan] [PATC
> -Original Message-
> From: Intel-wired-lan On Behalf Of
> Sergey Temerkhanov
> Sent: Wednesday, August 21, 2024 6:40 PM
> To: intel-wired-...@lists.osuosl.org
> Cc: Temerkhanov, Sergey ;
> net...@vger.kernel.org; Simon Horman ; Kitszel, Przemyslaw
>
> Subject: [Intel-wired-lan] [PATC
> -Original Message-
> From: Intel-wired-lan On Behalf Of
> Sergey Temerkhanov
> Sent: Wednesday, August 21, 2024 6:40 PM
> To: intel-wired-...@lists.osuosl.org
> Cc: Temerkhanov, Sergey ;
> net...@vger.kernel.org; Simon Horman
> Subject: [Intel-wired-lan] [PATCH iwl-next v6 3/5] ice: I
> -Original Message-
> From: Intel-wired-lan On Behalf Of
> Sergey Temerkhanov
> Sent: Wednesday, August 21, 2024 6:40 PM
> To: intel-wired-...@lists.osuosl.org
> Cc: Temerkhanov, Sergey ;
> net...@vger.kernel.org; Simon Horman ; Kitszel, Przemyslaw
>
> Subject: [Intel-wired-lan] [PATC
> -Original Message-
> From: Intel-wired-lan On Behalf Of Karol
> Kolacinski
> Sent: Friday, August 30, 2024 4:37 PM
> To: intel-wired-...@lists.osuosl.org
> Cc: net...@vger.kernel.org; Kubalewski, Arkadiusz
> ; Kolacinski, Karol
> ; Nguyen, Anthony L ;
> Simon Horman ; Kitszel, Przemy
> -Original Message-
> From: Intel-wired-lan On Behalf Of
> Sergey Temerkhanov
> Sent: Wednesday, August 21, 2024 6:40 PM
> To: intel-wired-...@lists.osuosl.org
> Cc: Temerkhanov, Sergey ;
> net...@vger.kernel.org; Simon Horman ; Kitszel, Przemyslaw
>
> Subject: [Intel-wired-lan] [PATC
> -Original Message-
> From: Intel-wired-lan On Behalf Of Karol
> Kolacinski
> Sent: Friday, August 30, 2024 4:37 PM
> To: intel-wired-...@lists.osuosl.org
> Cc: net...@vger.kernel.org; Kubalewski, Arkadiusz
> ; Kolacinski, Karol
> ; Nguyen, Anthony L ;
> Simon Horman ; Kitszel, Przemy
> -Original Message-
> From: Intel-wired-lan On Behalf Of Karol
> Kolacinski
> Sent: Friday, August 30, 2024 4:37 PM
> To: intel-wired-...@lists.osuosl.org
> Cc: net...@vger.kernel.org; Kubalewski, Arkadiusz
> ; Kolacinski, Karol
> ; Nguyen, Anthony L ;
> Simon Horman ; Kitszel, Przemy
> -Original Message-
> From: Intel-wired-lan On Behalf Of Karol
> Kolacinski
> Sent: Friday, August 30, 2024 4:37 PM
> To: intel-wired-...@lists.osuosl.org
> Cc: net...@vger.kernel.org; Kubalewski, Arkadiusz
> ; Kolacinski, Karol
> ; Nguyen, Anthony L ;
> Simon Horman ; Kitszel, Przemy
> -Original Message-
> From: Intel-wired-lan On Behalf Of Karol
> Kolacinski
> Sent: Friday, August 30, 2024 4:37 PM
> To: intel-wired-...@lists.osuosl.org
> Cc: net...@vger.kernel.org; Kubalewski, Arkadiusz
> ; Kolacinski, Karol
> ; Nguyen, Anthony L ;
> Simon Horman ; Kitszel, Przemy
> -Original Message-
> From: Intel-wired-lan On Behalf Of Karol
> Kolacinski
> Sent: Friday, August 30, 2024 4:37 PM
> To: intel-wired-...@lists.osuosl.org
> Cc: net...@vger.kernel.org; Kubalewski, Arkadiusz
> ; Kolacinski, Karol
> ; Nguyen, Anthony L ;
> Hagvi, Yochai ; Simon Horman ;
> -Original Message-
> From: Intel-wired-lan On Behalf
> Of Kamal Heib
> Sent: Tuesday, September 3, 2024 8:26 PM
> To: intel-wired-...@lists.osuosl.org
> Cc: ivecera ; YangHang Liu ;
> net...@vger.kernel.org; Kamal Heib ; Nguyen, Anthony
> L ; Kitszel, Przemyslaw
> ; Jakub Kicinski ;
>
63 matches
Mail list logo
