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 a
> -Original Message-
> From: Intel-wired-lan On Behalf Of
> Ernesto Castellotti
> Sent: Thursday, February 15, 2024 7:34 AM
> To: Kitszel, Przemyslaw ; Nguyen, Anthony L
> ; intel-wired-lan@osuosl.org; Kwapulinski, Piotr
>
> Subject: Re: [Intel-wired-lan] [PATCH iwl-next v2] ixgbe: Add
On Tue, Feb 27, 2024 at 05:04:47PM +0100, Jiri Pirko wrote:
> Tue, Feb 27, 2024 at 04:41:52PM CET, and...@lunn.ch wrote:
> >> What if it would not be unique, should they then proceed to add generic
> >> (other word would be "common") param, and make the other driver/s use
> >> it? Without deprecati
Commit 6871a7de705b6f6a4046f0d19da9bcd689c3bc8e from iPXE project is
setting the MFS to 0x600 = 1536.
At boot time the i40e driver complains about it with
the following message but continues.
MFS for port 1 has been set below the default: 600
If the MTU size is increased, the driver acce
On Mon, Feb 26, 2024 at 07:29:10PM -0600, Andrew Lunn wrote:
> Convert the tables to make use of ETHTOOL link mode bits, rather than
> the old u32 SUPPORTED speeds. Make use of the linkmode helps to set
> bits and compare linkmodes. As a result, the _u32 members of keee are
> no longer used, a step
On Mon, Feb 26, 2024 at 07:29:08PM -0600, Andrew Lunn wrote:
> Make use of the existing linkmode helpers for converting PHY EEE
> register values into links modes, now that ethtool_keee uses link
> modes, rather than u32 values.
>
> Signed-off-by: Andrew Lunn
Reviewed-by: Simon Horman
Sat, Feb 24, 2024 at 01:44:06PM CET, ksund...@redhat.com wrote:
>Changing the MAC address of the VFs are not available
>via devlink. Add the function handlers to set and get
>the HW address for the VFs.
>
>Signed-off-by: Karthik Sundaravel
>---
> drivers/net/ethernet/intel/ice/ice_devlink.c | 88 +
Tue, Feb 27, 2024 at 04:41:52PM CET, and...@lunn.ch wrote:
>> What if it would not be unique, should they then proceed to add generic
>> (other word would be "common") param, and make the other driver/s use
>> it? Without deprecating the old method ofc.
>
>If it is useful, somebody else will copy i
On Sat, Feb 24, 2024 at 06:14:06PM +0530, Karthik Sundaravel wrote:
> Changing the MAC address of the VFs are not available
> via devlink. Add the function handlers to set and get
> the HW address for the VFs.
>
> Signed-off-by: Karthik Sundaravel
Reviewed-by: Simon Horman
> What if it would not be unique, should they then proceed to add generic
> (other word would be "common") param, and make the other driver/s use
> it? Without deprecating the old method ofc.
If it is useful, somebody else will copy it and it will become
common. If nobody copies it, its probably n
Tue, Feb 27, 2024 at 02:05:45PM CET, przemyslaw.kits...@intel.com wrote:
>On 2/27/24 13:17, Jiri Pirko wrote:
>> Tue, Feb 27, 2024 at 03:37:00AM CET, k...@kernel.org wrote:
>> > On Sun, 25 Feb 2024 08:18:00 +0100 Jiri Pirko wrote:
>> > > > Do you recall any specific param that got rejected from mlx
allnoconfig gcc
arc allyesconfig gcc
arc defconfig gcc
arc randconfig-001-20240227 gcc
arc randconfig-002-20240227 gcc
arc
Simplify stats accumulation logic to fix the case where we don't take
previous stat value into account, we should always respect it.
Main netdev stats of our PF (Tx/Rx packets/bytes) were reported orders of
magnitude too big during OpenStack reconfiguration events, possibly other
reconfiguration c
On 2/27/24 13:17, Jiri Pirko wrote:
Tue, Feb 27, 2024 at 03:37:00AM CET, k...@kernel.org wrote:
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 mlx
Tue, Feb 27, 2024 at 03:37:00AM CET, k...@kernel.org wrote:
>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
> -Original Message-
> From: Intel-wired-lan On Behalf Of
> Vinicius Costa Gomes
> Sent: Wednesday, February 21, 2024 5:27 AM
> To: intel-wired-...@lists.osuosl.org
> Cc: Neftin, Sasha ; Gomes, Vinicius
> ; net...@vger.kernel.org; richardcoch...@gmail.com;
> k...@linutronix.de; Brandebu
On 2/27/24 08:05, Jiri Pirko wrote:
Mon, Feb 26, 2024 at 04:11:23PM CET, mschm...@redhat.com 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 i
17 matches
Mail list logo
