Dear Takeru, Jakub and list,
On Wed, Oct 18, 2023 at 10:53:02AM +0900, takeru hayasaka wrote:
> > Let's forget about capabilities of Intel NICs for now - can you as a
> > user think of practical use cases where we'd want to turn on hashing
> > based on TEID for, e.g. gtpu6 and not gtpc6?
>
> of c
Hi Takeru,
On Wed, Oct 18, 2023 at 01:49:08AM +0900, takeru hayasaka wrote:
> I'm not very proficient in English, so I'm worried whether I can
> explain it well.
Don't worry, you were very clear in this e-mail.
> Therefore, I will try to briefly explain the flow and what kind of
> cases these ar
Hello:
This series was applied to netdev/net-next.git (main)
by David S. Miller :
On Sun, 15 Oct 2023 19:43:01 -0400 you wrote:
> The following patch set was initially a part of [1]. As the purpose of the
> original series was to add the support of the new hardware to the intel ice
> driver, the
Hi,
please allow me to revive this old thread...
On Thu, 2023-08-24 at 09:04 +0200, Jiri Pirko wrote:
> > Wed, Aug 23, 2023 at 09:13:34PM CEST, xuejun.zh...@intel.com wrote:
> > > >
> > > > On 8/22/2023 8:34 AM, Jiri Pirko wrote:
> > > > > > Tue, Aug 22, 2023 at 05:12:55PM CEST,k...@kernel.org
'san_addr' and 'mac_fcoeq' members of struct iavf_mac_info are unused.
'type' is write-only. Delete all three.
The function iavf_set_mac_type that sets 'type' also checks if the PCI
vendor ID is Intel. This is unnecessary. Delete the whole function.
If in the future there's a need for the MAC typ
> -Original Message-
> From: Michal Schmidt
> Sent: Wednesday, October 18, 2023 1:15 PM
> To: intel-wired-...@lists.osuosl.org
> Cc: Keller, Jacob E ; Drewek, Wojciech
> ; Brandeburg, Jesse
> ; Nguyen, Anthony L
> ; net...@vger.kernel.org
> Subject: [PATCH net-next] iavf: delete unused
Commit c87c938f62d8f1 ("i40e: Add VF VLAN pruning") added new
PF flag I40E_FLAG_VF_VLAN_PRUNING but its value collides with
existing I40E_FLAG_TOTAL_PORT_SHUTDOWN_ENABLED flag.
Move the affected flag at the end of the flags and fix its value.
Cc: Mateusz Palczewski
Signed-off-by: Ivan Vecera
--
> -Original Message-
> From: Intel-wired-lan On Behalf Of
> Drewek, Wojciech
> Sent: Tuesday, October 10, 2023 1:24 PM
> To: mschmidt ; intel-wired-...@lists.osuosl.org
> Cc: Radoslaw Tyl ; Nguyen, Anthony L
> ; Brandeburg, Jesse
>
> Subject: Re: [Intel-wired-lan] [PATCH net-next 1/5] iav
> -Original Message-
> From: Intel-wired-lan On Behalf Of
> Drewek, Wojciech
> Sent: Tuesday, October 10, 2023 2:08 PM
> To: mschmidt ; intel-wired-...@lists.osuosl.org
> Cc: Radoslaw Tyl ; Nguyen, Anthony L
> ; Brandeburg, Jesse
>
> Subject: Re: [Intel-wired-lan] [PATCH net-next 2/5] iav
> -Original Message-
> From: Intel-wired-lan On Behalf Of
> Drewek, Wojciech
> Sent: Tuesday, October 10, 2023 1:34 PM
> To: mschmidt ; intel-wired-...@lists.osuosl.org
> Cc: Radoslaw Tyl ; Nguyen, Anthony L
> ; Brandeburg, Jesse
>
> Subject: Re: [Intel-wired-lan] [PATCH net-next 3/5] iav
> -Original Message-
> From: Intel-wired-lan On Behalf Of
> Drewek, Wojciech
> Sent: Tuesday, October 10, 2023 3:56 PM
> To: mschmidt ; intel-wired-...@lists.osuosl.org
> Cc: Radoslaw Tyl ; Nguyen, Anthony L
> ; Brandeburg, Jesse
>
> Subject: Re: [Intel-wired-lan] [PATCH net-next 4/5] iav
> -Original Message-
> From: Intel-wired-lan On Behalf Of
> Drewek, Wojciech
> Sent: Tuesday, October 10, 2023 1:43 PM
> To: mschmidt ; intel-wired-...@lists.osuosl.org
> Cc: Radoslaw Tyl ; Nguyen, Anthony L
> ; Brandeburg, Jesse
>
> Subject: Re: [Intel-wired-lan] [PATCH net-next 5/5] iav
On 17. 10. 23 19:17, Jacob Keller wrote:
On 10/13/2023 10:07 AM, Ivan Vecera wrote:
Provide devlink .info_get callback to allow the driver to report
detailed version information. The following info is reported:
"serial_number" -> The PCI DSN of the adapter
"fw.mgmt" -> The version of t
On 10/18/23 13:26, Ivan Vecera wrote:
Commit c87c938f62d8f1 ("i40e: Add VF VLAN pruning") added new
PF flag I40E_FLAG_VF_VLAN_PRUNING but its value collides with
existing I40E_FLAG_TOTAL_PORT_SHUTDOWN_ENABLED flag.
Move the affected flag at the end of the flags and fix its value.
Cc: Mateusz Pa
Align devlink info versions with ice driver so change 'fw.mgmt'
version to be 2-digit version [major.minor], add 'fw.mgmt.build'
that reports mgmt firmware build number and use '"fw.psid.api'
for NVM format version instead of incorrect '"fw.psid'.
Additionally add missing i40e devlink documentation
On Wed, Oct 18, 2023 at 1:26 PM Drewek, Wojciech
wrote:
> > -Original Message-
> > From: Michal Schmidt
> > Sent: Wednesday, October 18, 2023 1:15 PM
> > To: intel-wired-...@lists.osuosl.org
> > Cc: Keller, Jacob E ; Drewek, Wojciech
> > ; Brandeburg, Jesse
> > ; Nguyen, Anthony L
> > ; n
Hi Harald-san and all.
Thank you for the review and comment!
> So only in case the user intentionally configures their network to use
> the same IP address for GTP-C and GTP-U traffic one will need to start
> distinguishing GTP-C and GTP-U on one host/NIC with the RSS mechanism:
> Steer the GTP-C
Cited commit introduced a neat way of updating next_to_clean that does
not require boundary checks on each increment. This was done by masking
the new value with (ring length - 1) mask. Problem is that this is
applicable only for power of 2 ring sizes, for every other size this
assumption can not b
Patch 1 adds the support at the Kernel level, allowing the user to set a
symmetric RSS hash for any flow type via:
# ethtool -N|-U eth0 rx-flow-hash s|d|f|n symmetric-xor
Support for the new "symmetric-xor" flag will be later sent to the
"ethtool" user-space tool.
Patch 2 fixes a long stand
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.
A NIC that supports "symmetric-xor" can achieve this
Fix the values of the ICE_AQ_VSI_Q_OPT_RSS_* registers. Shifting is
already done when the values are used, no need to double shift. Bug was
not discovered earlier since only ICE_AQ_VSI_Q_OPT_RSS_TPLZ (Zero) is
currently used.
Also, rename ICE_AQ_VSI_Q_OPT_RSS_XXX to ICE_AQ_VSI_Q_OPT_RSS_HASH_XXX
f
From: Qi Zhang
Refactor the driver to use a communication data structure for RSS
config. To do so we introduce the new ice_rss_hash_cfg struct, and then
pass it as an argument to several functions.
Also introduce enum ice_rss_cfg_hdr_type to specify a more granular and
flexible RSS configuration
The flow director and RSS blocks use separate methods to generate a
unique 64 bit ID for the flow. This is not extendable, especially for
the RSS that already uses all 64 bit space.
Refactor the flow generation API so that the ID is generated within
ice_flow_add_prof(). The FD and RSS blocks cache
From: Jeff Guo
The hash function in the E800 NICs is set per-VSI and a specific AQ
command is needed to modify the hash function. Use the AQ command to
enable setting the symmetric Toeplitz RSS hash function for any VSI.
When the Symmetric Toeplitz hash function is used, the hardware sets the
in
Allow the VFs to support symmetric RSS for any flow type. The symmetric
RSS will not be supported on PFs not advertising the ADV RSS Offload
flag (ADV_RSS_SUPPORT()), for example the E700 series (i40e).
Reviewed-by: Madhu Chittim
Signed-off-by: Ahmed Zaki
---
.../net/ethernet/intel/iavf/iavf_ad
On Wed, 18 Oct 2023 10:53:02 +0900 takeru hayasaka wrote:
> For instance, there are PGWs that have the capability to separate the
> termination of communication of 4G LTE users into Control and User
> planes (C/U).
> This is quite convenient from a scalability perspective. In fact, in
> 5G UPF, the
On Wed, 18 Oct 2023 10:12:44 +0200 Harald Welte wrote:
> > If we were to propose again, setting aside considerations specific to
> > Intel, I believe, considering the users of ethtool, the smallest units
> > should be gtpu4|6 and gtpc4|6.
>
> agreed. Though I'm not entirely sure one would usual
On Wed, 18 Oct 2023 11:06:29 -0600 Ahmed Zaki wrote:
> v5: move sanity checks from ethtool/ioctl.c to ice's and iavf's rxfnc
> drivers entries (patches 5 and 6).
What about the discussion with Alex?
I thought you'd move the flag out of RXH_ into a separate field,
key-preproc, sub-algo, whateve
Hi Jakub,
On Wed, Oct 18, 2023 at 10:37:03AM -0700, Jakub Kicinski wrote:
> Harald went further and questioned use of the same IP addresses for
> -U and -C traffic, but even within one endpoint aren't these running
> on a different port?
yes.
> Can someone reasonably use the same UDP port for
On Tue, Oct 17, 2023 at 5:34 PM Jakub Kicinski wrote:
>
> On Tue, 17 Oct 2023 13:41:18 -0700 Alexander Duyck wrote:
> > I am thinking of this from a software engineering perspective. This
> > symmetric-xor aka simplified-toeplitz is actually much cheaper to
> > implement in software than the origi
On 2023-10-18 11:57, Jakub Kicinski wrote:
On Wed, 18 Oct 2023 11:06:29 -0600 Ahmed Zaki wrote:
v5: move sanity checks from ethtool/ioctl.c to ice's and iavf's rxfnc
drivers entries (patches 5 and 6).
What about the discussion with Alex?
I thought you'd move the flag out of RXH_ into a
On 9/22/2023 04:40, Vinicius Costa Gomes wrote:
We can re-use the IGC_SET_FLAG() macro to simplify setting some values
in the TX data descriptor. With the macro it's easier to get the
meaning of the operations.
Signed-off-by: Vinicius Costa Gomes
---
drivers/net/ethernet/intel/igc/igc_main.c
On Tue, Oct 10, 2023, at 03:39, Skyler Mäntysaari wrote:
> On Tue, Oct 10, 2023, at 02:50, Skyler Mäntysaari wrote:
>> On Mon, Oct 9, 2023, at 18:33, Jesse Brandeburg wrote:
>>> On 10/4/2023 10:08 AM, Skyler Mäntysaari wrote:
>> Hi there,
>>
>> It seems that for reasons unknown to me, m
On 10/18/2023 5:35 AM, Ivan Vecera wrote:
> Align devlink info versions with ice driver so change 'fw.mgmt'
> version to be 2-digit version [major.minor], add 'fw.mgmt.build'
> that reports mgmt firmware build number and use '"fw.psid.api'
> for NVM format version instead of incorrect '"fw.psid'
On 10/18/2023 4:15 AM, Michal Schmidt wrote:
> 'san_addr' and 'mac_fcoeq' members of struct iavf_mac_info are unused.
> 'type' is write-only. Delete all three.
>
> The function iavf_set_mac_type that sets 'type' also checks if the PCI
> vendor ID is Intel. This is unnecessary. Delete the whole
On 10/18/2023 9:39 AM, Maciej Fijalkowski wrote:
> Cited commit introduced a neat way of updating next_to_clean that does
> not require boundary checks on each increment. This was done by masking
> the new value with (ring length - 1) mask. Problem is that this is
> applicable only for power of
From: Pawel Chmielewski
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 for new link speeds. As the new devices
From: Alice Michael
Add the support for 200G phy speeds and the mapping for their
advertisement in link. Add the new PHY type bits for AQ command, as
needed for 200G E830 controllers.
Signed-off-by: Alice Michael
Co-developed-by: Pawel Chmielewski
Signed-off-by: Pawel Chmielewski
Reviewed-by:
E830 is the 200G NIC family which uses the ice driver.
Add specific E830 registers. Embed macros to use proper register based on
(hw)->mac_type & name those macros to [ORIGINAL]_BY_MAC(hw). Registers
only available on one of the macs will need to be explicitly referred to
as E800_NAME instead of j
The Get Link Status data length can vary with different versions of
ice_aqc_get_link_status_data. Add ice_get_link_status_datalen() to return
datalen for the specific ice_aqc_get_link_status_data version.
Add new link partner fields to ice_aqc_get_link_status_data; PHY type,
FEC, and flow control.
From: Pawel Chmielewski
Remove zeroing of the fields, as all the fields are in fact initialized
with zeros automatically
Reviewed-by: Jesse Brandeburg
Signed-off-by: Pawel Chmielewski
Reviewed-by: Simon Horman
Signed-off-by: Paul Greenwalt
---
drivers/net/ethernet/intel/ice/ice_main.c | 54
From: Dan Nowlin
Add support for E830 DDP package segment. For the E830 package,
signature buffers will not be included inline in the configuration
buffers. Instead, the signature buffers will be located in a
signature segment.
Reviewed-by: Jesse Brandeburg
Signed-off-by: Dan Nowlin
Co-develop
From: Pawel Chmielewski
As the previous patches provide support for E830 hardware, add E830
specific IDs to the PCI device ID table, so these devices can now be
probed by the kernel.
Reviewed-by: Jesse Brandeburg
Signed-off-by: Pawel Chmielewski
Reviewed-by: Simon Horman
Signed-off-by: Paul G
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 of
44 matches
Mail list logo
