Re: [Intel-wired-lan] [PATCH iwl-next v3 13/13] vfio/ice: Implement vfio_pci driver for E800 devices
On 10/4/2023 6:04 AM, Alex Williamson wrote: On Mon, 18 Sep 2023 06:25:46 + Yahui Cao wrote: From: Lingyu Liu Add a vendor-specific vfio_pci driver for E800 devices. It uses vfio_pci_core to register to the VFIO subsystem and then implements the E800 specific logic to support VF live migration. It implements the device state transition flow for live migration. Signed-off-by: Lingyu Liu Signed-off-by: Yahui Cao --- MAINTAINERS | 7 + drivers/vfio/pci/Kconfig| 2 + drivers/vfio/pci/Makefile | 2 + drivers/vfio/pci/ice/Kconfig| 10 + drivers/vfio/pci/ice/Makefile | 4 + drivers/vfio/pci/ice/ice_vfio_pci.c | 707 6 files changed, 732 insertions(+) create mode 100644 drivers/vfio/pci/ice/Kconfig create mode 100644 drivers/vfio/pci/ice/Makefile create mode 100644 drivers/vfio/pci/ice/ice_vfio_pci.c The prerequisite ice core driver support (ie. patches 1-12) should be supplied as a branch to allow this variant driver to be merged through the vfio tree. Tony, are you the right one who can help on deal with ice driver and variant driver merging dependency ? diff --git a/MAINTAINERS b/MAINTAINERS index 389fe9e38884..09ea8454219a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -22608,6 +22608,13 @@ L: k...@vger.kernel.org S:Maintained F:drivers/vfio/pci/mlx5/ +VFIO ICE PCI DRIVER +M: Yahui Cao +M: Lingyu Liu +L: k...@vger.kernel.org +S: Maintained +F: drivers/vfio/pci/ice/ + VFIO PCI DEVICE SPECIFIC DRIVERS R:Jason Gunthorpe R:Yishai Hadas diff --git a/drivers/vfio/pci/Kconfig b/drivers/vfio/pci/Kconfig index 8125e5f37832..6618208947af 100644 --- a/drivers/vfio/pci/Kconfig +++ b/drivers/vfio/pci/Kconfig @@ -65,4 +65,6 @@ source "drivers/vfio/pci/hisilicon/Kconfig" source "drivers/vfio/pci/pds/Kconfig" +source "drivers/vfio/pci/ice/Kconfig" + endmenu diff --git a/drivers/vfio/pci/Makefile b/drivers/vfio/pci/Makefile index 45167be462d8..fc1df82df3ac 100644 --- a/drivers/vfio/pci/Makefile +++ b/drivers/vfio/pci/Makefile @@ -13,3 +13,5 @@ obj-$(CONFIG_MLX5_VFIO_PCI) += mlx5/ obj-$(CONFIG_HISI_ACC_VFIO_PCI) += hisilicon/ obj-$(CONFIG_PDS_VFIO_PCI) += pds/ + +obj-$(CONFIG_ICE_VFIO_PCI) += ice/ diff --git a/drivers/vfio/pci/ice/Kconfig b/drivers/vfio/pci/ice/Kconfig new file mode 100644 index ..4c6f348d3062 --- /dev/null +++ b/drivers/vfio/pci/ice/Kconfig @@ -0,0 +1,10 @@ +# SPDX-License-Identifier: GPL-2.0-only +config ICE_VFIO_PCI + tristate "VFIO support for Intel(R) Ethernet Connection E800 Series" + depends on ICE + depends on VFIO_PCI_CORE s/depends on/select/ Sure. Will change to select VFIO_PCI_CORE + help + This provides migration support for Intel(R) Ethernet connection E800 + series devices using the VFIO framework. + + If you don't know what to do here, say N. diff --git a/drivers/vfio/pci/ice/Makefile b/drivers/vfio/pci/ice/Makefile new file mode 100644 index ..259d4ab89105 --- /dev/null +++ b/drivers/vfio/pci/ice/Makefile @@ -0,0 +1,4 @@ +# SPDX-License-Identifier: GPL-2.0-only +obj-$(CONFIG_ICE_VFIO_PCI) += ice-vfio-pci.o +ice-vfio-pci-y := ice_vfio_pci.o + diff --git a/drivers/vfio/pci/ice/ice_vfio_pci.c b/drivers/vfio/pci/ice/ice_vfio_pci.c new file mode 100644 index ..60a0582d7932 --- /dev/null +++ b/drivers/vfio/pci/ice/ice_vfio_pci.c Suggest renaming this to main.c If changing this to drivers/vfio/pci/ice/main.c, it may cause some naming conflict with networking driver file drivers/net/ethernet/intel/ice/ice_main.c and confusion. Could we still use ice_vfio_pci.c ? Since this variant driver only has single c source file( like hisilicon variant driver ) Thanks. Yahui. ___ Intel-wired-lan mailing list Intel-wired-lan@osuosl.org https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
Re: [Intel-wired-lan] [PATCH iwl-next v3 13/13] vfio/ice: Implement vfio_pci driver for E800 devices
On 10/4/2023 8:25 PM, Jason Gunthorpe wrote: On Tue, Oct 03, 2023 at 04:04:21PM -0600, Alex Williamson wrote: +/** + * ice_vfio_pci_load_state - VFIO device state reloading + * @ice_vdev: pointer to ice vfio pci core device structure + * + * Load device state and restore it. This function is called when the VFIO uAPI + * consumer wants to load the device state info from VFIO migration region and + * restore them into the device. This function should make sure all the device + * state info is loaded and restored successfully. As a result, return value is + * mandatory to be checked. + * + * Return 0 for success, negative value for failure. + */ Kudos on the kernel-doc comments throughout, nice! This appears to be a substantial improvement from the comments I see on v2, I'm curious where Kevin and Jason stand on this now. Thanks, It is on my todo list, but I haven't been able to look Did the fundamental issue with operating the VF from the VFIO driver get fully fixed? Jason Yes, I think so. In this version, with Kevin's guidance and help, there is not DMA read/write guest memory any more. VFIO driver will not operate VF and guest memory. You can refer to Patch10 for more details. Thanks. Yahui. ___ Intel-wired-lan mailing list Intel-wired-lan@osuosl.org https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
Re: [Intel-wired-lan] [PATCH net-next v2 1/6] net: ethtool: allow symmetric RSS hash for any flow type
On Fri, Oct 6, 2023 at 7:22 PM Jakub Kicinski wrote: > > On Fri, 6 Oct 2023 16:47:21 -0600 Ahmed Zaki wrote: > > Symmetric RSS hash functions are beneficial in applications that monitor > > both Tx and Rx packets of the same flow (IDS, software firewalls, ..etc). > > Getting all traffic of the same flow on the same RX queue results in > > higher CPU cache efficiency. > > > > Only fields that has counterparts in the other direction can be > > accepted; IP src/dst and L4 src/dst ports. > > > > The user may request RSS hash symmetry for a specific flow type, via: > > > > # ethtool -N|-U eth0 rx-flow-hash s|d|f|n symmetric > > > > or turn symmetry off (asymmetric) by: > > > > # ethtool -N|-U eth0 rx-flow-hash s|d|f|n > > Thanks for the changes, code looks good! > > The question left unanswered is whether we should care about the exact > implementation of the symmetry (xor, xor duplicate, sort fields). > Toeplitz-based RSS is very precisely specified, so we may want to carry > that precision into the symmetric behavior. I have a weak preference > to do so... but no willingness to argue with you, so let me put Willem > on the spot and have him make a decision :) I do have a stronger willingness to argue, thanks ;-) Can we give a more precise name, such as symmetric-xor? In case another device would implement another mode, such as the symmetric toeplitz of __flow_hash_consistentify, it would be good to be able to discern the modes. ___ Intel-wired-lan mailing list Intel-wired-lan@osuosl.org https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
Re: [Intel-wired-lan] [PATCH net-next v3 2/5] dpll: spec: add support for pin-dpll signal phase offset/adjust
Fri, Oct 06, 2023 at 09:44:57PM CEST, k...@kernel.org wrote:
>On Fri, 6 Oct 2023 18:53:04 +0200 Jiri Pirko wrote:
>> Fri, Oct 06, 2023 at 04:55:36PM CEST, k...@kernel.org wrote:
>> >> I'm confused. Didn't you say you'll remove this? If not, my question
>> >> from v1 still stands.
>> >
>> >Perhaps we should dis-allow setting version in non-genetlink-legacy
>> >specs? I thought it may be a useful thing to someone, at some point,
>> >but so far the scoreboard is: legit uses: 0, confused uses: 1 :S
>> >
>> >Thoughts?
>>
>> I don't know what the meaning of version is. I just never saw that being
>> touched. Is there any semantics documented for it?
>>
>> Kuba, any opinion?
>
>/me switches the first name in From :P
I messed up a bit. Kuba* confusion, sorry :)
>
>I think it basically predates the op / policy introspection,
>and allows people to break backward compat.
>
>drop_monitor bumped to 2 in 2009:
>
> 683703a26e46 ("drop_monitor: Update netlink protocol to include
>netlink attribute header in alert message")
>
>which breaks backward compat.
>
>genetlink ctrl went to 2 in 2006:
>
> 334c29a64507 ("[GENETLINK]: Move command capabilities to flags.")
>
>which moves some info around in attrs, also breaks backward compat
>if someone depended on the old placement.
>
>ovs did it in 2013:
>
> 44da5ae5fbea ("openvswitch: Drop user features if old user space
>attempted to create datapath")
>
>again, breaks backwards compat.
>
>
>I guess it may still make one day to bump the version for some proto
>which has very tight control over the user space. But it hasn't
>happened for 10 years.
But since by the policy we cannot break uapi compat, version should be
never bumped. I wonder howcome it is legit in the examples you listed
above...
Let's forbid that in genetlink.yaml. I have a patch ready, please ack
this approach.
Thx!
___
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
Re: [Intel-wired-lan] [PATCH iwl-net v2 5/5] ice: Document tx_scheduling_layers parameter
On Fri, Oct 06, 2023 at 07:02:12AM -0400, Mateusz Polchlopek wrote: > From: Michal Wilczynski > > New driver specific parameter 'tx_scheduling_layers' was introduced. > Describe parameter in the documentation. > > Signed-off-by: Michal Wilczynski > Reviewed-by: Przemek Kitszel > Co-developed-by: Mateusz Polchlopek > Signed-off-by: Mateusz Polchlopek Hi, I'm not expert here, but this seems to cause a splat when building documentation. .../ice.rst:70: WARNING: Unexpected indentation. .../ice.rst:25: WARNING: Error parsing content block for the "list-table" directive: uniform two-level bullet list expected, but row 2 does not contain the same number of items as row 1 (3 vs 4). .. list-table:: Driver-specific parameters implemented :widths: 5 5 5 85 * - Name - Type - Mode - Description * - ``tx_scheduling_layers`` - u8 - permanent The ice hardware uses hierarchical scheduling for Tx with a fixed number of layers in the scheduling tree. Root node is representing a port, while all the leaves represents the queues. This way of configuring Tx scheduler allows features like DCB or devlink-rate (documented below) for fine-grained configuration how much BW is given to any given queue or group of queues, as scheduling parameters can be configured at any given layer of the tree. By default 9-layer tree topology was deemed best for most workloads, as it gives optimal performance to configurability ratio. However for some specific cases, this might not be the case. A great example would be sending traffic to queues that is not a multiple of 8. Since in 9-layer topology maximum number of children is limited to 8, the 9th queue has a different parent than the rest, and it's given more BW credits. This causes a problem when the system is sending traffic to 9 queues: | tx_queue_0_packets: 24163396 | tx_queue_1_packets: 24164623 | tx_queue_2_packets: 24163188 | tx_queue_3_packets: 24163701 | tx_queue_4_packets: 24163683 | tx_queue_5_packets: 24164668 | tx_queue_6_packets: 23327200 | tx_queue_7_packets: 24163853 | tx_queue_8_packets: 91101417 < Too much traffic is sent to 9th Sometimes this might be a big concern, so the idea is to empower the user to switch to 5-layer topology, enabling performance gains but sacrificing configurability for features like DCB and devlink-rate. This parameter gives user flexibility to choose the 5-layer transmit scheduler topology. After switching parameter reboot is required for the feature to start working. User could choose 9 (the default) or 5 as a value of parameter, e.g.: $ devlink dev param set pci/:16:00.0 name tx_scheduling_layers value 5 cmode permanent And verify that value has been set: $ devlink dev param show pci/:16:00.0 name tx_scheduling_layers ___ Intel-wired-lan mailing list Intel-wired-lan@osuosl.org https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
[Intel-wired-lan] [tnguy-next-queue:dev-queue] BUILD SUCCESS e1126dcf9f6bd3ca5e88c55e08ca72ff7315ca50
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue.git dev-queue branch HEAD: e1126dcf9f6bd3ca5e88c55e08ca72ff7315ca50 ixgbe: fix end of loop test in ixgbe_set_vf_macvlan() elapsed time: 1400m configs tested: 107 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: alpha allnoconfig gcc alphaallyesconfig gcc alpha defconfig gcc arc allmodconfig gcc arc allnoconfig gcc arc allyesconfig gcc arc defconfig gcc arc randconfig-001-20231007 gcc arm allmodconfig gcc arm allnoconfig gcc arm allyesconfig gcc arm defconfig gcc arm randconfig-001-20231007 gcc arm64allmodconfig gcc arm64 allnoconfig gcc arm64allyesconfig gcc arm64 defconfig gcc csky allmodconfig gcc csky allnoconfig gcc csky allyesconfig gcc cskydefconfig gcc i386 allmodconfig gcc i386 allnoconfig gcc i386 allyesconfig gcc i386 buildonly-randconfig-001-20231007 gcc i386 buildonly-randconfig-002-20231007 gcc i386 buildonly-randconfig-003-20231007 gcc i386 buildonly-randconfig-004-20231007 gcc i386 buildonly-randconfig-005-20231007 gcc i386 buildonly-randconfig-006-20231007 gcc i386 debian-10.3 gcc i386defconfig gcc i386 randconfig-001-20231007 gcc i386 randconfig-002-20231007 gcc i386 randconfig-003-20231007 gcc i386 randconfig-004-20231007 gcc i386 randconfig-005-20231007 gcc i386 randconfig-006-20231007 gcc loongarchallmodconfig gcc loongarch allnoconfig gcc loongarchallyesconfig gcc loongarch defconfig gcc loongarch randconfig-001-20231007 gcc m68k allmodconfig gcc m68k allnoconfig gcc m68k allyesconfig gcc m68kdefconfig gcc microblaze allmodconfig gcc microblazeallnoconfig gcc microblaze allyesconfig gcc microblaze defconfig gcc mips allmodconfig gcc mips allnoconfig gcc mips allyesconfig gcc nios2allmodconfig gcc nios2 allnoconfig gcc nios2allyesconfig gcc nios2 defconfig gcc openrisc allmodconfig gcc openrisc allnoconfig gcc openrisc allyesconfig gcc openriscdefconfig gcc parisc allmodconfig gcc pariscallnoconfig gcc parisc allyesconfig gcc parisc defconfig gcc parisc64defconfig gcc powerpc allmodconfig gcc powerpc allnoconfig gcc powerpc allyesconfig gcc riscvallmodconfig gcc riscv allnoconfig gcc riscvallyesconfig gcc riscv defconfig gcc riscv rv32_defconfig gcc s390 allmodconfig gcc s390 allnoconfig gcc s390 allyesconfig gcc s390defconfig gcc sh allmodconfig gcc shallnoconfig gcc sh allyesconfig gcc sh defconfig gcc sparcallmodconfig gcc sparc allnoconfig gcc sparc
[Intel-wired-lan] [tnguy-net-queue:dev-queue] BUILD SUCCESS 13e5bef535438fbbfc61b47e4444bba768edb187
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue.git dev-queue branch HEAD: 13e5bef535438fbbfc61b47ebba768edb187 ixgbe: fix crash with empty VF macvlan list elapsed time: 1447m configs tested: 122 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: alpha allnoconfig gcc alphaallyesconfig gcc alpha defconfig gcc arc allmodconfig gcc arc allnoconfig gcc arc allyesconfig gcc arc defconfig gcc arc randconfig-001-20231007 gcc arm allmodconfig gcc arm allnoconfig gcc arm allyesconfig gcc arm defconfig gcc arm mxs_defconfig clang armqcom_defconfig gcc arm randconfig-001-20231007 gcc arm64allmodconfig gcc arm64 allnoconfig gcc arm64allyesconfig gcc arm64 defconfig gcc csky allmodconfig gcc csky allnoconfig gcc csky allyesconfig gcc cskydefconfig gcc i386 allmodconfig gcc i386 allnoconfig gcc i386 allyesconfig gcc i386 buildonly-randconfig-001-20231007 gcc i386 buildonly-randconfig-002-20231007 gcc i386 buildonly-randconfig-003-20231007 gcc i386 buildonly-randconfig-004-20231007 gcc i386 buildonly-randconfig-005-20231007 gcc i386 buildonly-randconfig-006-20231007 gcc i386 debian-10.3 gcc i386defconfig gcc i386 randconfig-001-20231007 gcc i386 randconfig-002-20231007 gcc i386 randconfig-003-20231007 gcc i386 randconfig-004-20231007 gcc i386 randconfig-005-20231007 gcc i386 randconfig-006-20231007 gcc loongarchallmodconfig gcc loongarch allnoconfig gcc loongarchallyesconfig gcc loongarch defconfig gcc loongarch randconfig-001-20231007 gcc m68k allmodconfig gcc m68k allnoconfig gcc m68k allyesconfig gcc m68kdefconfig gcc microblaze allmodconfig gcc microblazeallnoconfig gcc microblaze allyesconfig gcc microblaze defconfig gcc mips allmodconfig gcc mips allnoconfig gcc mips allyesconfig gcc mips bmips_be_defconfig gcc mips rt305x_defconfig gcc mips sb1250_swarm_defconfig clang nios2allmodconfig gcc nios2 allnoconfig gcc nios2allyesconfig gcc nios2 defconfig gcc openrisc allmodconfig gcc openrisc allnoconfig gcc openrisc allyesconfig gcc openriscdefconfig gcc parisc allmodconfig gcc pariscallnoconfig gcc parisc allyesconfig gcc parisc defconfig gcc parisc64defconfig gcc powerpc allmodconfig gcc powerpc allnoconfig gcc powerpc allyesconfig gcc powerpcgamecube_defconfig clang riscv allnoconfig gcc riscvallyesconfig gcc riscv defconfig gcc riscv randconfig-001-20231008 gcc riscv rv32_defconfig gcc s390 allnoconfig gcc s390 allyesconfig gcc s390defconfig gcc s390 randconfig-001-20231008 gcc sh
