On Fri, 14 Jun 2024 05:58:17 -0700 Anil Samal wrote:
> To debug link issues in the field, serdes Tx/Rx equalizer values
> help to determine the health of serdes lane.
>
> Extend 'ethtool -d' option to dump serdes Tx/Rx equalizer.
> The following list of equalizer param is supported
> a.
On Thu, 13 Jun 2024 17:36:16 +0200 Larysa Zaremba wrote:
> > > AFAIK, netif_device_detach() does not affect .ndo_bpf() calls. We were
> > > trying
> > > such approach with idpf and it does work for ethtool, but not for XDP.
> >
> > I reckon that's an unintentional omission. In theory XDP is
On Thu, 13 Jun 2024 10:54:12 +0200 Larysa Zaremba wrote:
> > > The locking mechanisms I use here do not look pretty, but if I am not
> > > missing
> > > anything, the synchronization they provide must be robust.
> >
> > Robust as in they may be correct here, but you lose lockdep and all
> >
On Thu, 13 Jun 2024 12:47:33 +0200 Alexander Lobakin wrote:
> > Having per-driver grouping defines is a no-go.
>
> Without it, kdoc warns when I want to describe group fields =\
>
> > Do you need the defines in the first place?
>
> They allow to describe CLs w/o repeating boilerplates like
On Sun, 9 Jun 2024 17:33:50 + Asbjørn Sloth Tønnesen wrote:
> Now that all drivers properly rejects unsupported flower control flags
> used with FLOW_DISSECTOR_KEY_CONTROL, then time has come to add similar
> checks to the drivers supporting FLOW_DISSECTOR_KEY_ENC_CONTROL.
Thanks for doing
On Wed, 12 Jun 2024 08:56:38 +0200 Larysa Zaremba wrote:
> On Tue, Jun 11, 2024 at 07:38:37PM -0700, Jakub Kicinski wrote:
> > On Mon, 10 Jun 2024 17:37:12 +0200 Larysa Zaremba wrote:
> > > Fix the problems that are triggered by tx_timeout and ice_xdp() calls,
> &g
On Wed, 12 Jun 2024 12:07:05 +0200 Przemek Kitszel wrote:
> Given that it will be a generic solution (would fix the [1] above),
> and be also easier to use, like:
>
> CACHELINE_STRUCT_GROUP(idpf_q_vector,
> CACHELINE_STRUCT_GROUP_RD(/* read mostly */
> struct idpf_vport
On Mon, 10 Jun 2024 17:37:12 +0200 Larysa Zaremba wrote:
> Fix the problems that are triggered by tx_timeout and ice_xdp() calls,
> including both pool and program operations.
Is there really no way for ice to fix the locking? :(
The busy loops and trylocks() are not great, and seem like duct
On Fri, 7 Jun 2024 14:15:52 +0200 Dawid Osuchowski wrote:
> We cannot use ice_wait_for_reset() since both the ethtool handler and the
> adapter reset flow call rtnl_lock() during operation. If we wait for
> reset completion inside of an ethtool handling function such as
> ice_get_coalesce(), the
h 1 fixed:
Reviewed-by: Jakub Kicinski
queue stats next? :]
On Tue, 4 Jun 2024 15:13:21 -0700 Jesse Brandeburg wrote:
> - - `ETHTOOL_MSG_PAUSE_GET`
>- `ETHTOOL_MSG_FEC_GET`
> + - 'ETHTOOL_MSG_LINKSTATE_GET'
>- `ETHTOOL_MSG_MM_GET`
> + - `ETHTOOL_MSG_PAUSE_GET`
> + - 'ETHTOOL_MSG_TSINFO_GET'
I was going to steal this directly but:
` vs '
so
On Tue, 28 May 2024 15:48:45 +0200 Alexander Lobakin wrote:
> Currently, idpf uses the following model for the header buffers:
>
> * buffers are allocated via dma_alloc_coherent();
> * when receiving, napi_alloc_skb() is called and then the header is
> copied to the newly allocated linear part.
On Tue, 28 May 2024 15:48:35 +0200 Alexander Lobakin wrote:
> diff --git a/scripts/kernel-doc b/scripts/kernel-doc
> index 95a59ac78f82..d0cf9a2d82de 100755
> --- a/scripts/kernel-doc
> +++ b/scripts/kernel-doc
> @@ -1155,6 +1155,7 @@ sub dump_struct($$) {
> $members =~
On Tue, 28 May 2024 07:23:00 -0400 Mateusz Polchlopek wrote:
> + .ndo_eth_ioctl = iavf_do_ioctl,
Please use the new ndos:
* int (*ndo_hwtstamp_get)(struct net_device *dev,
* struct kernel_hwtstamp_config *kernel_config);
* Get the currently configured
On Tue, 28 May 2024 13:01:32 +0200 Wojciech Drewek wrote:
> Subject: [PATCH iwl-net v2] ice: Add support for devlink loopback param.
iwl-next, presumably
Param makes sense, although the name keeps giving me pause.
I expect "loopback" will control either port loopback or something
like hairpin.
On Fri, 26 Apr 2024 15:22:02 +0200 Przemek Kitszel wrote:
> ## devlink resources (with current API)
> `devlink resource` is compelling, partially given the name sounds like a
> perfect match. But when we dig just a little bit, the current Path+sizes
> (min,max,step) is totally off to what is the
On Fri, 26 Apr 2024 12:10:35 +0200 Alexander Gordeev wrote:
> On Wed, Apr 24, 2024 at 05:16:56PM +0200, Alexander Gordeev wrote:
> > Applied, thanks!
>
> Hi Jakub,
>
> I just want to make sure you do not have plans to pull this patch
> via the net tree, right? (I schedulled it for the s390
On Mon, 15 Apr 2024 13:15:41 +0300 Lifshits, Vitaly wrote:
> Thank you for this patch and this observation.
> I think that you found a real misbehaviour in the original patch.
> However, I still think that forcing SMBUS functionality shouldn't be
> part of the ULP enabling flow, since they are
On Thu, 11 Apr 2024 11:07:24 +0200 Alexander Lobakin wrote:
> > I think doc tree is a strong candidate, or at least we should not
> > merge without consulting Jon. Please post and we'll figure it out.
>
> Can this series go simultaneously or it needs to wait for the fix first?
You can send
On Wed, 10 Apr 2024 15:36:13 +0200 Alexander Lobakin wrote:
> Which tree this should go through? Should I include this patch to this
> series with libeth or it's better to push this through kees/linux and
> then pull to net-next?
I think doc tree is a strong candidate, or at least we should not
On Thu, 4 Apr 2024 17:44:00 +0200 Alexander Lobakin wrote:
> +/**
> + * struct libeth_fq - structure representing a buffer queue
> + * @fp: hotpath part of the structure
Second time this happens this week, so maybe some tooling change in 6.9
but apparently kdoc does not want to know about the
On Wed, 3 Apr 2024 09:19:20 -0400 Mateusz Polchlopek wrote:
> --- a/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c
> +++ b/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c
> @@ -145,6 +145,7 @@ int iavf_send_vf_config_msg(struct iavf_adapter *adapter)
> VIRTCHNL_VF_OFFLOAD_CRC |
>
On Wed, 3 Apr 2024 12:19:57 +0200 Wojciech Drewek wrote:
> You're saying that if min_pwr_allowed or max_pwr_allowed taken from get op
> are 0 than we should not allow to set max_pwr_reset and max_pwr_set?
Yes, return -EOPNOTSUPP and point extack at whatever max_pwr attr user
sent. If driver
On Tue, 2 Apr 2024 16:46:54 +0200 Andrew Lunn wrote:
> Looking at
> https://www.optcore.net/wp-content/uploads/2017/04/QSFP-MSA.pdf table
> 7 it indicates different power budget classifications. Power level 1
> is a Maximum power of 1.5W. So does your parameter represent this? It
> is the minimum
On Tue, 2 Apr 2024 13:25:07 +0200 Wojciech Drewek wrote:
> On 29.03.2024 23:29, Jakub Kicinski wrote:
> > On Fri, 29 Mar 2024 10:23:20 +0100 Wojciech Drewek wrote:
> >> Some modules use nonstandard power levels. Adjust ethtool
> >> module implementation to support new
On Tue, 2 Apr 2024 13:38:59 +0200 Wojciech Drewek wrote:
> > Also, this is about the board, the SFP cage, not the actual SFP
> > module? Maybe the word cage needs to be in these names?
>
> It's about cage. Thanks for bringing it to my attention because now I
> see it might be misleading. I'm
On Fri, 29 Mar 2024 10:23:20 +0100 Wojciech Drewek wrote:
> Some modules use nonstandard power levels. Adjust ethtool
> module implementation to support new attributes that will allow user
> to change maximum power.
>
> Add three new get attributes:
> ETHTOOL_A_MODULE_MAX_POWER_SET (used for set
On Fri, 29 Mar 2024 10:23:18 +0100 Wojciech Drewek wrote:
> Some ethernet modules use nonstandard power levels [1]. Extend ethtool
> module implementation to support new attributes that will allow user
> to change maximum power. Rename structures and functions to be more
> generic. Introduce an
On Wed, 27 Mar 2024 09:25:31 -0400 Mateusz Polchlopek wrote:
> v2:
> - fixed warning related to wrong specifier to dev_err_once in
> commit 7
> - fixed warnings related to unused variables in commit 9
You posted this yesterday and got no feedback.
You're not posting to the list just to get the
On Tue, 26 Mar 2024 17:41:15 +0100 Alexander Lobakin wrote:
> To ease maintaining of virtchnl2.h, which already is messy enough,
> make it self-contained by adding missing if_ether.h include due to
> %ETH_ALEN usage.
> At the same time, virtchnl2_lan_desc.h is not used anywhere in the
> file, so
Alexander Lobakin
Signed-off-by: Jakub Kicinski
---
v2:
- remove gfp_mask from kdoc
v1: https://lore.kernel.org/all/20240325224116.2585741-1-k...@kernel.org/
CC: al...@kernel.org
CC: siyant...@loongson.cn
CC: jesse.brandeb...@intel.com
CC: anthony.l.ngu...@intel.com
CC: alexandre.tor...@foss
allocation
failures via the queue stat API (qstats::rx-alloc-fail).
The direct motivation for this patch is that one of the drivers
used at Meta calls napi_alloc_skb() (so prior to this patch without
__GFP_NOWARN), and the resulting OOM warning is the top networking
warning in our fleet.
Signed-off
On Fri, 22 Mar 2024 03:24:56 -0400 (EDT) Julia Lawall wrote:
> > At present I find this construct unreadable.
> > I may get used to it, hard to say.
> >
> > Also I don't see the benefit of the auto-freeing construct,
> > I'd venture a guess that all the bugs it may prevent would
> > have been
On Thu, 21 Mar 2024 18:48:28 -0700 Jakub Kicinski wrote:
> On Thu, 21 Mar 2024 15:27:47 -0700 Jesse Brandeburg wrote:
> > The gist of it is that we should instead be using inline declarations,
> > which I also agree is a reasonable style for this. It more clearly shows
>
On Thu, 21 Mar 2024 15:27:47 -0700 Jesse Brandeburg wrote:
> The gist of it is that we should instead be using inline declarations,
> which I also agree is a reasonable style for this. It more clearly shows
> the __free(kfree) and the allocation (kzalloc, kcalloc, etc) on the same
> (or
On Wed, 20 Mar 2024 08:01:49 +0300 Dan Carpenter wrote:
> > This is just trading one kind of bug for another, and the __free()
> > magic is at a cost of readability.
> >
> > I think we should ban the use of __free() in all of networking,
> > until / unless it cleanly handles the NULL init case.
On Sat, 16 Mar 2024 12:44:40 +0300 Dan Carpenter wrote:
> - struct ice_aqc_get_phy_caps_data *pcaps __free(kfree);
> - void *mac_buf __free(kfree);
> + struct ice_aqc_get_phy_caps_data *pcaps __free(kfree) = NULL;
> + void *mac_buf __free(kfree) = NULL;
This is just trading one
On Fri, 8 Mar 2024 15:18:25 +0100 Alexander Lobakin wrote:
> Here's a two-shot: introduce {,Intel} Ethernet common library (libeth and
> libie) and switch iavf to Page Pool. Details are in the commit messages;
> here's a summary:
./scripts/kernel-doc reports some issues here
--
pw-bot: cr
On Sat, 09 Mar 2024 01:52:56 +0800 kernel test robot wrote:
> |-- i386-randconfig-141-20240308
> | `--
> drivers-net-ethernet-intel-i40e-i40e_main.c-i40e_veb_release()-error:uninitialized-symbol-vsi-.
Hi Tony!
Is this one on your radar? I suspect netdev@ gets CCed on the reports
because of
On Wed, 6 Mar 2024 22:55:48 +0800 Zou, Steven wrote:
> > We are seeing following kernel compilation error while compiling next
> > kernel:
> >
> > "error: dereferencing pointer to incomplete type 'struct dpll_pin'"
>
> Thanks Mayank!
> The patch does not touch 'stuct dpll_pin', I do not think
On Sat, 2 Mar 2024 01:50:03 +0100 Larysa Zaremba wrote:
> For RX: match on Ethertype and mirror, every trusted VF should be able to
> scan
> neighbors.
>
> For TX this is more complicated and is done not through eswitch, but through
> modifying security options, so do not think this would work
chlopek
> Signed-off-by: Mateusz Polchlopek
Acked-by: Jakub Kicinski
On Thu, 29 Feb 2024 20:33:04 +0100 Larysa Zaremba wrote:
> > This is an LLDP agent which runs as part of the NIC FW, AFAIU, not about
> > forwarding or filtering.
> >
> > They already have the priv flag, so best to reuse that. If not possible
> > we can explore options, but as Larysa mentioned
struct net_device poll_dev in struct igc_q_vector was added
in one of the initial commits, but never used.
Signed-off-by: Jakub Kicinski
---
CC: jesse.brandeb...@intel.com
CC: anthony.l.ngu...@intel.com
---
drivers/net/ethernet/intel/igc/igc.h | 1 -
1 file changed, 1 deletion(-)
diff --git
On Thu, 29 Feb 2024 10:20:05 +0100 Jiri Pirko wrote:
> But isn't it a matter of eswitch configuration? I mean, the user should
> be free to configure filtering/forwarding of any packet, including LLDP
> ones.
This is an LLDP agent which runs as part of the NIC FW, AFAIU, not about
forwarding or
On Wed, 28 Feb 2024 16:59:44 +0100 Larysa Zaremba wrote:
> Allow to:
> * receive LLDP packets on a VF
> * transmit LLDP from a VF
>
> Only a single VF per port can transmit LLDP packets,
> all trusted VFs can transmit LLDP packets.
>
> For both functionalities to work, private flag
>
On Mon, 26 Feb 2024 16:11:23 +0100 Michal Schmidt wrote:
> There is a need for synchronization between ice PFs on the same physical
> adapter.
>
> Add a "struct ice_adapter" for holding data shared between PFs of the
> same multifunction PCI device. The struct is refcounted - each ice_pf
> holds
On Sun, 25 Feb 2024 08:18:00 +0100 Jiri Pirko wrote:
> >Do you recall any specific param that got rejected from mlx5?
> >Y'all were allowed to add the eq sizing params, which I think
> >is not going to be mlx5-only for long. Otherwise I only remember
> >cases where I'd try to push people to use
On Fri, 23 Feb 2024 10:45:01 +0100 Jiri Pirko wrote:
>> Jiri, I'm not aware of any other devices with this sort of trade off.
>> We shouldn't add the param if either:
>> - this can be changed dynamically as user instantiates rate limiters;
>> - we know other devices have similar needs.
>> If
On Thu, 22 Feb 2024 14:25:21 +0100 Mateusz Polchlopek wrote:
> >> This is kind of proprietary param similar to number of which were shot
> >> down for mlx5 in past. Jakub?
> >
> > I remain somewhat confused about what this does.
> > Specifically IIUC the problem is that the radix of each node
On Mon, 19 Feb 2024 13:37:36 +0100 Jiri Pirko wrote:
> >devlink dev param show pci/:4b:00.0 name tx_scheduling_layers
> >pci/:4b:00.0:
> > name tx_scheduling_layers type driver-specific
> >values:
> > cmode permanent value 9
> >
> >Set:
> >devlink dev param set pci/:4b:00.0
On Tue, 13 Feb 2024 14:16:47 +0100 Alexander Lobakin wrote:
> > Fix softirq's not being handled during napi_schedule() call when
> > receiving marker packets for queue disable by disabling local bottom
> > half.
>
> BTW, how exactly does this help?
>
> __napi_schedule() already disables
On Fri, 9 Feb 2024 18:09:57 -0800 Jesse Brandeburg wrote:
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> @@ -10416,14 +10416,11 @@ static const struct net_device_ops ixgbe_netdev_ops
> = {
> .ndo_setup_tc =
On Wed, 7 Feb 2024 19:53:52 -0800 Saeed Mahameed wrote:
> From: Tariq Toukan
>
> Add documentation for the feature and some details on some design decisions.
Thanks.
> diff --git
> a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/sd.rst
>
On Thu, 8 Feb 2024 16:34:49 +0900 Takeru Hayasaka wrote:
> Hello Jakub-san, and all reviewers and maintainers,
>
> It has been a week since I last received any feedback on this patch. I
> apologize for the inconvenience during this busy period, but I would
> greatly appreciate it if you could
On Tue, 6 Feb 2024 13:46:44 +0100 Alexander Lobakin wrote:
> > Add support for creating PFCP filters in switchdev mode. Add pfcp module
> > that allows to create a PFCP-type netdev. The netdev then can be passed to
> > tc when creating a filter to indicate that PFCP filter should be created.
>
On Tue, 6 Feb 2024 22:50:25 + Keller, Jacob E wrote:
> > Hm, okay, that does sound like making it worse.
> > I'll disable the minmax coccicheck for now, it seems noisy.
>
> Maybe you could make the coccicheck only complain if the value is
> non-zero or not const? Maybe that's a bit too
On Tue, 6 Feb 2024 11:18:48 -0800 Alan Brady wrote:
> We did run coccinelle check and see the min suggestions. It's triggering
> on these statements I added:
>
> return reply_sz < 0 ? reply_sz : 0;
>
> A min here would change it to:
>
> return min(reply_sz, 0);
>
> I didn't really like that
On Mon, 5 Feb 2024 19:37:54 -0800 Alan Brady wrote:
> The motivation for this series has two primary goals. We want to enable
> support of multiple simultaneous messages and make the channel more
> robust. The way it works right now, the driver can only send and receive
> a single message at a
On Tue, 6 Feb 2024 13:46:44 +0100 Alexander Lobakin wrote:
> > Add support for creating PFCP filters in switchdev mode. Add pfcp module
> > that allows to create a PFCP-type netdev. The netdev then can be passed to
> > tc when creating a filter to indicate that PFCP filter should be created.
>
On Wed, 24 Jan 2024 15:29:38 +0100 Linux regression tracking (Thorsten
Leemhuis) wrote:
> >> I think that's a bad bisect. There is no reason I could understand for
> >> that change to cause a continuous or large leak, it really doesn't make
> >> any sense. Reverting it consistently helps? You're
On Wed, 31 Jan 2024 13:46:22 + Takeru Hayasaka wrote:
> .../device_drivers/ethernet/intel/ice.rst | 21 -
> drivers/net/ethernet/intel/ice/ice_ethtool.c | 82 +++
> drivers/net/ethernet/intel/ice/ice_flow.h | 31 +--
> drivers/net/ethernet/intel/ice/ice_lib.c
On Mon, 18 Dec 2023 21:12:35 +0100 Paolo Abeni wrote:
> On Fri, 2023-12-15 at 14:41 -0800, Jakub Kicinski wrote:
> > I explained before (perhaps on the netdev call) - Qdiscs have two
> > different offload models. "local" and "switchdev", here we want "loca
Hi folks,
many people are on winter break already, so there will be no netdev
call tomorrow.
This weeks reviewers are: Intel
Happy holidays everyone!
___
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
On Fri, 15 Dec 2023 12:06:52 +0100 Paolo Abeni wrote:
> > uAPI aside, why would we use ndo_setup_tc(TC_SETUP_QDISC_TBF)
> > to implement common basis?
> >
> > Is it not cleaner to have a separate driver API, with its ops
> > and capabilities?
>
> We understand one of the end goal is
On Thu, 14 Dec 2023 21:29:51 +0100 Paolo Abeni wrote:
> Together with Simon, I spent some time on the above. We think the
> ndo_setup_tc(TC_SETUP_QDISC_TBF) hook could be used as common basis for
> this offloads, with some small extensions (adding a 'max_rate' param,
> too).
uAPI aside, why would
On Tue, 12 Dec 2023 15:05:19 -0800 Jesse Brandeburg wrote:
> On 12/12/2023 1:28 PM, Jakub Kicinski wrote:
> > On Mon, 11 Dec 2023 10:59:27 +0800 Kunwu Chan wrote:
> >> kasprintf() returns a pointer to dynamically allocated memory
> >> which can be NULL upon failure.
&g
On Mon, 11 Dec 2023 10:59:27 +0800 Kunwu Chan wrote:
> kasprintf() returns a pointer to dynamically allocated memory
> which can be NULL upon failure.
>
> Fixes: 1978d3ead82c ("intel: fix string truncation warnings")
No need for the allocation here, print to a buffer on the stack.
--
pw-bot: cr
On Mon, 11 Dec 2023 11:13:36 +0800 Kunwu Chan wrote:
> kasprintf() returns a pointer to dynamically allocated memory
> which can be NULL upon failure.
>
> Fixes: 1978d3ead82c ("intel: fix string truncation warnings")
> Cc: Kunwu Chan
> Signed-off-by: Kunwu Chan
The allocation is rather
w,
> so add SET first. I suspect idpf is not the only one supporting this.
Reviewed-by: Jakub Kicinski
___
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
On Mon, 11 Dec 2023 11:16:20 +0100 Alexander Lobakin wrote:
> Ideally, I'd like to pass a CPU ID this queue will be run on and use
> cpu_to_node(), but currently there's no NUMA-aware allocations in the
> Intel drivers and Rx queues don't get the corresponding CPU ID when
> configuring. I may
On Wed, 6 Dec 2023 16:36:35 -0700 Ahmed Zaki wrote:
> - rxfh.indir_size = dev_indir_size;
> - rxfh.key_size = dev_key_size;
> + rxfh.indir_size = rxfh_dev.indir_size;
> + rxfh.key_size = rxfh_dev.key_size;
> if (copy_to_user(useraddr, , sizeof(rxfh)))
> return
On Thu, 7 Dec 2023 18:20:02 +0100 Alexander Lobakin wrote:
> Ever since build_skb() became stable, the old way with allocating an skb
> for storing the headers separately, which will be then copied manually,
> was slower, less flexible, and thus obsolete.
This one has a conflict on net-next :(
On Thu, 7 Dec 2023 11:16:10 +0100 Przemek Kitszel wrote:
> I have let know our igc TL, architect, and anybody that could be
> interested via cc: IWL. And I'm happy that this could be done at
> relaxed pace thanks to Johannes
I think you may be expecting us to take Johannes's patch.
It's still on
On Tue, 5 Dec 2023 16:00:41 -0700 Ahmed Zaki wrote:
> Patches 1 and 2 modify the get/set_rxh ethtool API to take a pointer to
> struct of parameters instead of individual params. This will allow future
> changes to the uAPI-shared struct ethtool_rxfh without changing the
> drivers' API.
Looks
On Mon, 04 Dec 2023 22:32:25 +0100 Johannes Berg wrote:
> Well, I was hoping that
>
> (a) ethtool folks / Jakub would comment if this makes sense, but I
> don't see a good reason to do things the other way around (other
> than "code is simpler"); and
My opinion on RPM is pretty
CC: Intel Wired
https://lore.kernel.org/all/20231204004003.gb29...@merlins.org/
On Mon, 04 Dec 2023 11:57:44 +0100 Johannes Berg wrote:
> On Sun, 2023-12-03 at 23:35 -0800, Marc MERLIN wrote:
> > So, I thought that maybe my custom built kernel had options that somehow
> > made P17 unhappy, and
On Fri, 1 Dec 2023 15:59:49 -0800 Pawel Kaminski wrote:
> Add support for devlink loopback param. Supported values are "enabled",
> "disabled" and "prioritized". Default configuration is set to "enabled.
>
> By default loopback traffic BW is locked to PF configured BW.
First off -
On Thu, 30 Nov 2023 17:45:10 +0100 Alexander Lobakin wrote:
> > Meh, this way the stats won't survive ifdown/ifup cycles as usually
> > page_pools get destroyed on ifdown :z
> > In that patch, I backup the PP stats to a device-lifetime container when
> > the pool gets destroyed, maybe we could do
On Wed, 29 Nov 2023 14:40:33 +0100 Alexander Lobakin wrote:
> > Expand the libie generic per-queue stats with the generic Page Pool
> > stats provided by the API itself, when CONFIG_PAGE_POOL_STATS is
> > enabled. When it's not, there'll be no such fields in the stats
> > structure, so no space
On Mon, 27 Nov 2023 16:15:47 -0800 Zhang, Xuejun wrote:
> This is extension of ndo_set_tx_maxrate to include per queue parameters
> of tx_minrate and burst.
>
> devlink rate api includes tx_maxrate and tx_minrate, it is intended for
> port rate configurations.
>
> With regarding to tc mqprio,
On Mon, 27 Nov 2023 15:32:19 +0100 Alexander Lobakin wrote:
> > Sorry for not remembering the suggestion:(
>
> In the previous versions of this change I used a global flag per whole
> page_pool, just like XSk does for the whole XSk buff pool, then you
> proposed to use the lowest bit of
On Mon, 27 Nov 2023 17:10:37 + Edward Cree wrote:
> Yep, I had noticed. Was wondering how the removal of the old
> [sg]et_rxfh_context functions would interact with my new API,
> which has three ops (create/modify/delete) and thus can't
> really be wedged into the [sg]et_rxfh() like that.
On Mon, 27 Nov 2023 07:21:47 -0700 Ahmed Zaki wrote:
> On 2023-11-21 16:33, Jakub Kicinski wrote:
> > On Mon, 20 Nov 2023 13:56:09 -0700 Ahmed Zaki wrote:
> >> + * @data: Extension for the RSS hash function. Valid values are one of the
> >> + *%RXH_HFUNC_*.
On Mon, 27 Nov 2023 07:14:51 -0700 Ahmed Zaki wrote:
> > - First simplify the code by always providing a pointer to all params
> > (indir, key and func); the fact that some of them may be NULL seems
> > like a weird historic thing or a premature optimization.
> > It will simplify the
On Fri, 24 Nov 2023 16:47:19 +0100 Alexander Lobakin wrote:
> - long frag_users;
> + long frag_users __aligned(4 * sizeof(long));
A comment for the somewhat unusual alignment size would be good.
___
Intel-wired-lan mailing list
On Thu, 23 Nov 2023 15:33:04 +0200 Gal Pressman wrote:
> On 22/11/2023 1:33, Jakub Kicinski wrote:
> > Last but not least please keep the field check you moved to the drivers
> > in the core. Nobody will remember to check that other drivers added the
> > check as wel
On Mon, 20 Nov 2023 13:56:09 -0700 Ahmed Zaki wrote:
> + * @data: Extension for the RSS hash function. Valid values are one of the
> + * %RXH_HFUNC_*.
@data is way too generic. Can we call this key_xfrm? key_preproc?
> +/* RSS hash function data
> + * XOR the corresponding source and
On Mon, 20 Nov 2023 13:56:08 -0700 Ahmed Zaki wrote:
> u32 (*get_rxfh_key_size)(struct net_device *);
> u32 (*get_rxfh_indir_size)(struct net_device *);
> - int (*get_rxfh)(struct net_device *, u32 *indir, u8 *key,
> - u8 *hfunc);
> - int
Hi,
The bi-weekly netdev call at https://bbb.lwn.net/b/jak-wkr-seg-hjn
is scheduled tomorrow at 8:30 am (PT) / 5:30 pm (~EU).
So far the only agenda item is a minor update on CI,
please send other topics!
In terms of the review rotation - this week's reviewer is Intel.
On Thu, 16 Nov 2023 21:52:49 -0800 Zhang, Xuejun wrote:
> Thanks for looking into our last patch with devlink API. Really
> appreciate your candid review.
>
> Following your suggestion, we have looked into 3 tc offload options to
> support queue rate limiting
>
> #1 mq + matchall + police
>
>
Hi!
Here are the stats for netdev 6.7 limited to Intel folks:
Top reviewers (thr): Top reviewers (msg):
10 (+19) [6] Jacob Keller 9 (+23) [12] Jacob Keller
15 (***) [3] Wojciech Drewek 24 (***) [ 4] Wojciech Drewek
16 (+19)
On Tue, 31 Oct 2023 18:13:20 +0200 Gal Pressman wrote:
> Sure, IIUC, ice's implementation does a:
> (SRC_IP ^ DST_IP, SRC_IP ^ DST_IP, SRC_PORT ^ DST_PORT, SRC_PORT ^ DST_PORT)
>
> Our implementation isn't exactly xor, it is:
> (SRC_IP | DST_IP, SRC_IP ^ DST_IP, SRC_PORT | DST_PORT, SRC_PORT ^
On Tue, 31 Oct 2023 09:14:58 -0600 Ahmed Zaki wrote:
> Do you mean add vendor-specific implementation details to common docs?
> Not sure if I have seen this before. Any examples?
>
> Or, we can add a note in ethtool doc that each vendor's implementation
> is different and "Refer to your
On Thu, 26 Oct 2023 11:23:37 +0200 Przemek Kitszel wrote:
> this would now fit into one line
> (perhaps it's the same in other cases, I just checked this one manually)
I think cocci would fold lines automatically? Could be worth trying
spatch to do the conversion for that reason, if you aren't
On Thu, 19 Oct 2023 09:13:46 +0200 Michal Schmidt wrote:
> It is not safe to initialize the waitqueues after queueing the
> watchdog_task. It will be using them.
>
> The chance of this causing a real problem is very small, because
> there will be some sleeping before any of the waitqueues get
On Fri, 20 Oct 2023 17:14:11 -0600 Ahmed Zaki wrote:
> I replied to that here:
>
> https://lore.kernel.org/all/afb4a06f-cfba-47ba-adb3-09bea7cb5...@intel.com/
>
> I am kind of confused now so please bear with me. ethtool either sends
> "ethtool_rxfh" or "ethtool_rxnfc". AFAIK "ethtool_rxfh" is
On Fri, 20 Oct 2023 15:24:41 -0600 Ahmed Zaki wrote:
> > IMO fat warning in the documentation and ethtool man saying that this
> > makes the algo (any / all) vulnerable to attack would be enough.
> > Willem?
>
> Please advise on the next step. Should I send a new version with the Doc
>
On Wed, 18 Oct 2023 19:16:37 -0400 Paul Greenwalt wrote:
> This is an initial patchset adding the basic support for E830. E830 is
> the 200G ethernet controller family that is a follow on to the E810 100G
> family. The series adds new devices IDs, a new MAC type, several registers
> and a support
On Wed, 18 Oct 2023 11:12:13 -0700 Alexander Duyck wrote:
> > > Based on earlier comments it doesn't change the inputs, it just
> > > changes how I have to handle the data and the key. It starts reducing
> > > things down to something like the Intel implementation of Flow
> > > Director in terms
1 - 100 of 125 matches
Mail list logo
