>-Original Message-
>From: Intel-wired-lan On Behalf Of
>Fijalkowski, Maciej
>Sent: Wednesday, May 29, 2024 4:54 PM
>To: intel-wired-...@lists.osuosl.org
>Cc: Fijalkowski, Maciej ; Zaremba, Larysa
>; net...@vger.kernel.org; Kubiak, Michal
>; Nguyen, Anthony L
>; Karlsson, Magnus
>
>Subj
>-Original Message-
>From: Intel-wired-lan On Behalf Of
>Fijalkowski, Maciej
>Sent: Wednesday, May 29, 2024 4:54 PM
>To: intel-wired-...@lists.osuosl.org
>Cc: Fijalkowski, Maciej ; Zaremba, Larysa
>; net...@vger.kernel.org; Kubiak, Michal
>; Nguyen, Anthony L
>; Karlsson, Magnus
>
>Subj
>-Original Message-
>From: Intel-wired-lan On Behalf Of
>Fijalkowski, Maciej
>Sent: Wednesday, May 29, 2024 4:54 PM
>To: intel-wired-...@lists.osuosl.org
>Cc: Fijalkowski, Maciej ; Zaremba, Larysa
>; net...@vger.kernel.org; Kubiak, Michal
>; Nguyen, Anthony L
>; Karlsson, Magnus
>
>Subj
>-Original Message-
>From: Intel-wired-lan On Behalf Of
>Fijalkowski, Maciej
>Sent: Wednesday, May 29, 2024 4:54 PM
>To: intel-wired-...@lists.osuosl.org
>Cc: Fijalkowski, Maciej ; Zaremba, Larysa
>; net...@vger.kernel.org; Kubiak, Michal
>; Nguyen, Anthony L
>; Karlsson, Magnus
>
>Subj
>-Original Message-
>From: Intel-wired-lan On Behalf Of
>Fijalkowski, Maciej
>Sent: Wednesday, May 29, 2024 4:54 PM
>To: intel-wired-...@lists.osuosl.org
>Cc: Fijalkowski, Maciej ; Zaremba, Larysa
>; net...@vger.kernel.org; Kubiak, Michal
>; Nguyen, Anthony L
>; Karlsson, Magnus
>
>Subj
>-Original Message-
>From: Intel-wired-lan On Behalf Of
>Fijalkowski, Maciej
>Sent: Wednesday, May 29, 2024 4:54 PM
>To: intel-wired-...@lists.osuosl.org
>Cc: Fijalkowski, Maciej ; Zaremba, Larysa
>; net...@vger.kernel.org; Kubiak, Michal
>; Nguyen, Anthony L
>; Karlsson, Magnus
>
>Subj
>-Original Message-
>From: Intel-wired-lan On Behalf Of
>Fijalkowski, Maciej
>Sent: Wednesday, May 29, 2024 4:54 PM
>To: intel-wired-...@lists.osuosl.org
>Cc: Fijalkowski, Maciej ; Zaremba, Larysa
>; net...@vger.kernel.org; Kubiak, Michal
>; Nguyen, Anthony L
>; Karlsson, Magnus
>
>Subj
>-Original Message-
>From: Intel-wired-lan On Behalf Of
>Fijalkowski, Maciej
>Sent: Wednesday, May 29, 2024 4:54 PM
>To: intel-wired-...@lists.osuosl.org
>Cc: Fijalkowski, Maciej ; Zaremba, Larysa
>; net...@vger.kernel.org; Kubiak, Michal
>; Nguyen, Anthony L
>; Karlsson, Magnus
>
>Subj
On 6/3/2024 11:47 AM, Joshua Hay wrote:
There are several reasons for a TX completion to take longer than usual
to be written back by HW. For example, the completion for a packet that
misses a rule will have increased latency. The side effect of these
variable latencies for any given packet is o
On 6/3/2024 11:47 AM, Joshua Hay wrote:
> There are several reasons for a TX completion to take longer than usual
> to be written back by HW. For example, the completion for a packet that
> misses a rule will have increased latency. The side effect of these
> variable latencies for any given pac
There are several reasons for a TX completion to take longer than usual
to be written back by HW. For example, the completion for a packet that
misses a rule will have increased latency. The side effect of these
variable latencies for any given packet is out of order completions. The
stack sends pa
On Mon, Jun 03, 2024 at 02:38:30PM +0200, Jiri Pirko wrote:
> Mon, Jun 03, 2024 at 11:50:15AM CEST, michal.swiatkow...@linux.intel.com
> wrote:
> >From: Piotr Raczynski
> >
> >Make devlink allocation function generic to use it for PF and for SF.
> >
> >Add function for SF devlink port creation. I
>-Original Message-
>From: Simon Horman
>Sent: Friday, May 31, 2024 4:54 PM
>To: Kwapulinski, Piotr
>Cc: intel-wired-...@lists.osuosl.org; net...@vger.kernel.org; Keller, Jacob E
>; Wegrzyn, Stefan ;
>Jagielski, Jedrzej ; Glaza, Jan
>
>Subject: Re: [PATCH iwl-next v7 3/7] ixgbe: Add l
>-Original Message-
>From: Simon Horman
>Sent: Friday, May 31, 2024 4:50 PM
>To: Kwapulinski, Piotr
>Cc: intel-wired-...@lists.osuosl.org; net...@vger.kernel.org; Keller, Jacob E
>; Wegrzyn, Stefan ;
>Jagielski, Jedrzej ; Sokolowski, Jan
>
>Subject: Re: [PATCH iwl-next v7 2/7] ixgbe:
Mon, Jun 03, 2024 at 02:31:46PM CEST, wojciech.dre...@intel.com wrote:
>From: Pawel Kaminski
>
>Add support for driver-specific devlink local_forwarding param.
>Supported values are "enabled", "disabled" and "prioritized".
>Default configuration is set to "enabled".
>
>Add documentation in network
Mon, Jun 03, 2024 at 11:50:15AM CEST, michal.swiatkow...@linux.intel.com wrote:
>From: Piotr Raczynski
>
>Make devlink allocation function generic to use it for PF and for SF.
>
>Add function for SF devlink port creation. It will be used in next
>patch.
>
>Create header file for subfunction device
From: Pawel Kaminski
Add support for driver-specific devlink local_forwarding param.
Supported values are "enabled", "disabled" and "prioritized".
Default configuration is set to "enabled".
Add documentation in networking/devlink/ice.rst.
In previous generations of Intel NICs the transmit sched
From: Piotr Raczynski
Use previously implemented SF aux driver. It is probe during SF
activation and remove after deactivation.
Reviewed-by: Simon Horman
Signed-off-by: Piotr Raczynski
Signed-off-by: Michal Swiatkowski
---
.../ethernet/intel/ice/devlink/devlink_port.c | 173 +
Implement add / delete vlan for subfunction type VSI.
Reviewed-by: Simon Horman
Reviewed-by: Wojciech Drewek
Signed-off-by: Michal Swiatkowski
---
drivers/net/ethernet/intel/ice/Makefile | 1 +
.../ethernet/intel/ice/ice_sf_vsi_vlan_ops.c | 21 +++
.../ethernet/intel/ic
Flow for creating Tx topology is the same as for VF port representors,
but the devlink port is stored in different place (sf->devlink_port).
When creating VF devlink lock isn't taken, when creating subfunction it
is. Setting Tx topology function needs to take this lock, check if it
was taken befor
Subfunction port representor needs the basic netdevice ops to work
correctly. Create them.
Reviewed-by: Wojciech Drewek
Reviewed-by: Jiri Pirko
Signed-off-by: Michal Swiatkowski
---
drivers/net/ethernet/intel/ice/ice_repr.c | 57 +--
1 file changed, 43 insertions(+), 14 del
Now there is another type of port representor. Correct checking if
parent device is ready to reflect also new PR type.
Reviewed-by: Simon Horman
Reviewed-by: Wojciech Drewek
Signed-off-by: Michal Swiatkowski
---
drivers/net/ethernet/intel/ice/ice_ethtool.c | 7 +++
drivers/net/ethernet/in
Implement attaching and detaching SF port representor. It is done in the
same way as the VF port representor.
SF port representor is always added or removed with devlink
lock taken.
Reviewed-by: Simon Horman
Signed-off-by: Michal Swiatkowski
---
.../ethernet/intel/ice/devlink/devlink_port.c |
Add check for subfunction before setting target VSI. It is needed for PF
in switchdev mode but not for subfunction (even in switchdev mode).
Reviewed-by: Simon Horman
Signed-off-by: Michal Swiatkowski
---
drivers/net/ethernet/intel/ice/ice_txrx.c | 2 +-
1 file changed, 1 insertion(+), 1 deleti
Keep the same flow of port representor creation, but instead of general
attach function create helpers for specific representor type.
Store function pointer for add and remove representor.
Type of port representor can be also known based on VSI type, but it
is more clean to have it directly saved
From: Piotr Raczynski
Implement subfunction driver. It is probe when subfunction port is
activated.
VSI is already created. During the probe VSI is being configured.
MAC unicast and broadcast filter is added to allow traffic to pass.
Store subfunction pointer in VSI struct. The same is done for
From: Piotr Raczynski
Configure netdevice for subfunction usecase. Mostly it is reusing ops
from the PF netdevice.
SF netdev is linked to devlink port registered after SF activation.
Reviewed-by: Simon Horman
Reviewed-by: Jiri Pirko
Signed-off-by: Piotr Raczynski
Signed-off-by: Michal Swiatk
From: Piotr Raczynski
Make devlink allocation function generic to use it for PF and for SF.
Add function for SF devlink port creation. It will be used in next
patch.
Create header file for subfunction device. Define subfunction device
structure there as it is needed for devlink allocation and p
When subfunction VSI is open the same code as for PF VSI should be
executed. Also when up is complete. Reflect that in code by adding
subfunction VSI to consideration.
In case of stopping, PF doesn't have additional tasks, so the same
is with subfunction VSI.
Reviewed-by: Simon Horman
Signed-off
From: Piotr Raczynski
Implement devlink port handlers responsible for ethernet type devlink
subfunctions. Create subfunction devlink port and setup all resources
needed for a subfunction netdev to operate. Configure new VSI for each
new subfunction, initialize and configure interrupts and Tx/Rx r
From: Piotr Raczynski
Make some of the netdevice_ops functions visible from outside for
another VSI type created netdev.
Reviewed-by: Simon Horman
Reviewed-by: Przemek Kitszel
Reviewed-by: Wojciech Drewek
Signed-off-by: Piotr Raczynski
Signed-off-by: Michal Swiatkowski
---
drivers/net/ethe
From: Piotr Raczynski
Add required plumbing for new VSI type dedicated to devlink subfunctions.
Make sure that the vsi is properly configured and destroyed. Also allow
loading XDP and AF_XDP sockets.
The first implementation of devlink subfunctions supports only one Tx/Rx
queue pair per given su
Hi,
Currently ice driver does not allow creating more than one networking
device per physical function. The only way to have more hardware backed
netdev is to use SR-IOV.
Following patchset adds support for devlink port API. For each new
pcisf type port, driver allocates new VSI, configures all r
On 31.05.2024 12:36, Paul Menzel wrote:
> Dear Wojciech,
>
>
> Thank you for your patch.
>
> Am 31.05.24 um 11:32 schrieb Wojciech Drewek:
>> ice_aqc_opc_download_pkg (0x0C40) AQ sporadically returns error due
>> to FW issue. Fix this by retrying five times before moving to
>> Safe Mode.
>
>
fig and materials to reproduce are available at:
https://download.01.org/0day-ci/archive/20240603/202406031428.22e2b70a-...@intel.com
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
35 matches
Mail list logo
