Hi,
This is a series to prepare port representor for supporting also
subfunctions. We need correct devlink locking and the possibility to
update parent VSI after port representor is created.
Refactor how devlink lock is taken to suite the subfunction use case.
VSI configuration needs to be done
It is used to get representor structure during cleaning.
Reviewed-by: Wojciech Drewek
Signed-off-by: Michal Swiatkowski
---
drivers/net/ethernet/intel/ice/ice_eswitch_br.c | 4 +++-
drivers/net/ethernet/intel/ice/ice_eswitch_br.h | 1 +
drivers/net/ethernet/intel/ice/ice_repr.c | 7 ++
In case of subfunction lock will be taken for whole port creation. Do
the same in VF case.
Signed-off-by: Michal Swiatkowski
---
drivers/net/ethernet/intel/ice/devlink/devlink.c | 2 --
drivers/net/ethernet/intel/ice/devlink/devlink_port.c | 4 ++--
drivers/net/ethernet/intel/ice/ice_eswitc
It is needed because subfunction port representor shouldn't configure
the source VSI during representor creation.
Move the code to separate function and call it only in case the VF port
representor is being created.
Signed-off-by: Michal Swiatkowski
---
drivers/net/ethernet/intel/ice/ice_eswitc
In case of reset of VF VSI can be reallocated. To handle this case it
should be properly updated.
Reload representor as vsi->vsi_num can be different than the one stored
when representor was created.
Instead of only changing antispoof do whole VSI configuration for
eswitch.
Signed-off-by: Michal
Hi Sujai,
Thank you for testing.
On 5/6/24 5:32 AM, Buvaneswaran, Sujai wrote:
HW offload is not supported on the i40e interface. This patch cannot be tested
on i40e interface.
To me it looks like it's supported (otherwise there is a lot of dead flower
code in i40e_main.c),
although it's a
On Wed, Apr 24, 2024 at 02:08:11PM -0700, Tony Nguyen wrote:
>
>
> On 4/19/2024 10:13 AM, Michal Swiatkowski wrote:
>
> > +/**
> > + * ice_eswitch_cfg_vsi - configure VSI to work in slow-path
> > + * @vsi: VSI structure of representee
> > + * @mac: representee MAC
>
> Can you fix the kdoc for t
Hi Sujai,
Thank you for testing.
On 5/6/24 5:30 AM, Buvaneswaran, Sujai wrote:
HW offload is not directly supported on the iavf VF interface. VF traffic can
be offloaded only through VF port representor device which uses ice driver.
Again, there is a awful lot of flower code in iavf_main.c,
Hi Asbjørn,
I have tried the above steps as well and still issue is seen while enabling HW
offload on iavf interface.
[root@cbl-mariner ~]# ethtool -K ens5f0v0 hw-tc-offload on
Actual changes:
hw-tc-offload: off [requested on]
Could not change any device features
[root@cbl-mariner ~]# tc qdisc a
On 5/3/24 17:25, Thinh Tran wrote:
The patch fixes an issue when repeated EEH reports with a single error
on the bus of Intel X710 4-port 10G Base-T adapter, in the MSI domain
causing the devices to be permanently disabled. It fully resets and
restart the devices when handling the PCI EEH error.
Mon, May 06, 2024 at 10:46:49AM CEST, michal.swiatkow...@linux.intel.com wrote:
>Hi,
>
>This is a series to prepare port representor for supporting also
>subfunctions. We need correct devlink locking and the possibility to
>update parent VSI after port representor is created.
>
>Refactor how devlin
On 4/30/24 03:59, Jakub Kicinski wrote:
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,ste
From: Ngai-Mint Kwan
Getting coalesce settings while reset is in progress can cause NULL
pointer deference bug.
If under reset, abort get coalesce for ethtool.
Fixes: 67fe64d78c43 ("ice: Implement getting and setting ethtool coalesce")
Signed-off-by: Ngai-Mint Kwan
Reviewed-by: Mateusz Polchlop
On 03/05/2024 13:18, Ricky Wu wrote:
Originally, the sleep codes being moved forward only
ran if we met some conditions (e.g. BMSR_LSTATUS bit
not set in phy_status). Moving these sleep codes forward
makes the usec_interval take effect every time.
Signed-off-by: Ricky Wu
---
In v2:
* Split the
Thank you for your time.
Originally, sleep codes would only be executed if the first read fails
or the link status that is read is down. Some circumstances like the
[v2,2/2] "e1000e: fix link fluctuations problem" would need a delay
before first reading/accessing the PHY IEEE register, so that it
Hi,
> I haven't touched the ixgbe driver and hardware in many years, but I'll
try to see what I can do to help.
Thank you very much for your reply. I'll answer you point by point.
I upgraded the Qoton to Debian 13 (testing) with kernel 6.6.15 (amd64)
to be even more up to date.
A quick test wi
On 5/6/2024 1:44 AM, Asbjørn Sloth Tønnesen wrote:
Hi Sujai,
Thank you for testing.
On 5/6/24 5:32 AM, Buvaneswaran, Sujai wrote:
HW offload is not supported on the i40e interface. This patch cannot
be tested on i40e interface.
To me it looks like it's supported (otherwise there is a lot
On 5/4/2024 6:29 AM, kernel.org-fo5...@ycharbi.fr wrote:
> Hi,
>
> > I haven't touched the ixgbe driver and hardware in many years, but I'll
> try to see what I can do to help.
>
> Thank you very much for your reply. I'll answer you point by point.
> I upgraded the Qoton to Debian 13 (testing
On 5/6/2024 4:35 AM, Przemek Kitszel wrote:
In general do not add a blank line after Fixes tag.
Someone could complain that i40e driver had a bug prior to the cited
core commit, but for more practical purposes I find it good as is.
When you are a sender of the patch, it's good to place your S
On 4/29/2024 5:49 AM, Ross Lagerwall wrote:
When the PCI functions are created, Xen is informed about them and
caches the number of MSI-X entries each function has. However, the
number of MSI-X entries is not set until after the hardware has been
configured and the VFs have been started. This
On Thu, May 02, 2024 at 05:12:15PM +0800, Ricky Wu wrote:
> As described in https://bugzilla.kernel.org/show_bug.cgi?id=218642,
> some e1000e NIC reports link up -> link down -> link up when hog-plugging
> the Ethernet cable.
>
> The problem is because the unstable behavior of Link Status bit in
>
On 06/05/2024 19:46, En-Wei WU wrote:
Thank you for your time.
Originally, sleep codes would only be executed if the first read fails
or the link status that is read is down. Some circumstances like the
[v2,2/2] "e1000e: fix link fluctuations problem" would need a delay
before first reading/acce
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue.git 10GbE
branch HEAD: 8c4e4798123fd8e0c55e48e49db0f24287c18def Merge branch
'add-tcp-fraglist-gro-support'
elapsed time: 1202m
configs tested: 168
configs skipped: 3
The following configs have been built successful
On 06.05.24 23:18, Jacob Keller wrote:
> On 5/4/2024 6:29 AM, kernel.org-fo5...@ycharbi.fr wrote:
>> > Ideally, if you could use git bisect on the setup that could
>> > efficiently locate what regressed the behavior.
>> I really want to, but I have no idea how to go about it. Can you write
>> me
24 matches
Mail list logo
