Hi Hanoh,
Could you please explain what do you mean by *wrong hash value*?
i40e calculates hash value for TCP/UDP using 4-tuple: L3 source/destination
addresses and L4 source/destination ports. It does not use IP protocol, as TCP
and UDP already separated to different PCTYPEs at HW level. Could
> -Original Message-
> From: Rybalchenko, Kirill
> Sent: Thursday, February 1, 2018 12:43 PM
> To: dev@dpdk.org
> Cc: sta...@dpdk.org; Rybalchenko, Kirill ;
> Chilikin, Andrey ; Xing, Beilei
> ; Wu, Jingjing
> Subject: [PATCH v3] net/i40e: fix multiple DDP packages
> -Original Message-
> From: Mcnamara, John
> Sent: Friday, November 3, 2017 3:24 PM
> To: dev@dpdk.org
> Cc: Rybalchenko, Kirill ; Chilikin, Andrey
> ; Mcnamara, John
> Subject: [PATCH v1] i40e: highlight change to flexible payload for RSS config
>
> Add depr
Hi Wei,
Is there number of RX queues configured for the port?
If main_vsi->nb_used_qps reflects number of enabled RX queues, then it can be
used.
Regards,
Andrey
> -Original Message-
> From: Zhao1, Wei
> Sent: Wednesday, October 18, 2017 4:01 AM
> To: Chilikin, Andrey
Hi Wei
Sorry for the late comment, but I was not included to the patchset CC list and
just found this new version.
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Wei Zhao
> Sent: Wednesday, October 11, 2017 9:56 AM
> To: dev@dpdk.org
> Cc: Zhao1, Wei
> Subje
Hi Wei
> -Original Message-
> From: Zhao1, Wei
> Sent: Friday, September 22, 2017 9:49 AM
> To: Chilikin, Andrey ; dev@dpdk.org
> Cc: Yigit, Ferruh ; Xing, Beilei
> ; Wu, Jingjing
> Subject: RE: [dpdk-dev] [PATCH v3 1/2] net/i40e: queue region set and
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Wei Zhao
> Sent: Friday, September 15, 2017 4:13 AM
> To: dev@dpdk.org
> Cc: Zhao1, Wei
> Subject: [dpdk-dev] [PATCH v3 1/2] net/i40e: queue region set and flush
>
> This feature enable queue regions configuration
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Wei Zhao
> Sent: Wednesday, August 23, 2017 8:26 PM
> To: dev@dpdk.org
> Cc: Zhao1, Wei
> Subject: [dpdk-dev] [PATCH 1/2] net/i40e: queue region set and flush
>
> This feature enable queue regions configuration
> 03/08/2017 18:15, Stephen Hemminger:
> > On Thu, 3 Aug 2017 14:21:38 +0100
> > Bruce Richardson wrote:
> >
> > > On Thu, Aug 03, 2017 at 01:21:35PM +0100, Chilikin, Andrey wrote:
> > > > To control some device-specific features public device-specifi
To control some device-specific features public device-specific functions
rte_pmd_*.h are used.
But this solution requires applications to distinguish devices at runtime
and, depending on the device type, call corresponding device-specific
functions even if functions' parameters are the same.
IOC
Hi Beilei,
> -Original Message-
> From: Xing, Beilei
> Sent: Wednesday, June 28, 2017 7:58 AM
> To: Chilikin, Andrey ; dev@dpdk.org
> Cc: Wu, Jingjing
> Subject: RE: [PATCH v3 1/2] net/i40e: extended list of operations for ddp
> processing
>
> Hi Andrey,
With XL710 NICs you can use flexible payload for RSS for ETH_RSS_L2_PAYLOAD. By
default XL710 PMD will extract first 16 bytes of the payload. You can include
these 16 bytes for RSS with rte_eth_dev_filter_ctrl(...,RTE_ETH_FILTER_HASH,
RTE_ETH_FILTER_SET, ...)
/Andrey
-Original Message-
Hi Beilei
> -Original Message-
> From: Xing, Beilei
> Sent: Thursday, June 1, 2017 3:21 AM
> To: Chilikin, Andrey ; dev@dpdk.org
> Cc: Wu, Jingjing
> Subject: RE: [PATCH] net/i40e: get information about ddp profile
>
> Hi Andrey,
>
> > -Origina
PPPoE consists of two stages with different ethertypes - Discovery and Session,
so RTE_PTYPE_L2_ETHER_PPPOE looks ambiguous to me. This patch adds only PPPoE
Session Stage packet type. Should it include PPPoE Discovery Stage as well
(Ethertype x8863)?
/Andrey
> -Original Message-
> F
Hi Beilei
> -Original Message-
> From: Xing, Beilei
> Sent: Saturday, March 25, 2017 4:04 AM
> To: Chilikin, Andrey ; Wu, Jingjing
>
> Cc: Zhang, Helin ; dev@dpdk.org
> Subject: RE: [dpdk-dev] [PATCH v4 1/5] net/i40e: add pipeline personalization
> profile p
Hi Beilei,
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Beilei Xing
> Sent: Friday, March 24, 2017 10:19 AM
> To: Wu, Jingjing
> Cc: Zhang, Helin ; dev@dpdk.org
> Subject: [dpdk-dev] [PATCH v4 1/5] net/i40e: add pipeline personalization
> profile processing
While doing this fields reshuffling, any chance to put uint16_t vlan_tci_outer
beside uint16_t vlan_tci? It will allow to treat QinQ tags as a single 32-bit
tag, if needed, and use it for other tag/labels like MPLS, GRE, NSH which could
be 20, 24, 32 bits wide.
/Andrey
> -Original Message
In addition to Konstantin's point - some configuration settings, like RSS input
set and PTYPEs, could be firmware dependent and change between fw versions for
the same X710/X722 device. Moving mapping tables to the dev private data and
initializing it on device start up will make code much clean
Hi Sugesh,
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Chandran, Sugesh
> Sent: Friday, July 15, 2016 10:23 AM
> To: 'Adrien Mazarguil'
> > > > To PMD maintainers: please comment if you know devices that
> > > > support tagging matching packets with m
Hi Oliver,
> -Original Message-
> From: Olivier MATZ [mailto:olivier.matz at 6wind.com]
> Sent: Wednesday, July 6, 2016 1:09 PM
> To: Chilikin, Andrey ; Liang, Cunming
> ; dev at dpdk.org
> Cc: Ananyev, Konstantin
> Subject: Re: [dpdk-dev] [PATCH 05/18] mbuf: add f
Hi Oliver,
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Olivier MATZ
> Sent: Wednesday, July 6, 2016 8:43 AM
> To: Liang, Cunming ; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 05/18] mbuf: add function to get packet type
> from data
>
> Hi Cunming,
>
> -Original Message-
> From: Chilikin, Andrey
> Sent: Wednesday, September 30, 2015 10:16 AM
> To: dev at dpdk.org
> Cc: Chilikin, Andrey
> Subject: [PATCH] i40e: fix for default flexible payload registers settings
>
> This patch applies new default va
Hi Jingjing,
> -Original Message-
> From: Wu, Jingjing
> Sent: Thursday, January 21, 2016 1:29 AM
> To: Chilikin, Andrey; dev at dpdk.org
> Cc: Zhang, Helin; Pei, Yulong; Ananyev, Konstantin
> Subject: RE: [PATCH 2/4] i40e: split function for input set change of hash
at dpdk.org
> Cc: Wu, Jingjing; Zhang, Helin; Chilikin, Andrey; Pei, Yulong
> Subject: [PATCH 2/4] i40e: split function for input set change of hash and
> fdir
>
> This patch splited function for input set change of hash and fdir, and added a
> new function to set the input set
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jijiang Liu
> Sent: Monday, December 14, 2015 7:49 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v3] doc: announce ABI change for struct
> rte_eth_conf
>
> v2 change:
> Add more description for the cha
Hi Rahul,
If ABI for fdir is going to be changed should we then take more general
approach to accommodate other NICs as well? For example, for
"rte_eth_ipv4_flow" you have "tos" and "proto" fields added, but "ttl" was left
out of scope. I believe that "rte_eth_udpv6_flow" should be compatible
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jijiang Liu
> Sent: Monday, December 7, 2015 3:02 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH] doc: announce ABI change for struct rte_eth_conf
>
> Announce ABI change for struct rte_eth_conf.
>
> S
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of John McNamara
> Sent: Monday, November 2, 2015 5:46 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH] examples/l3fwd: fix eth-dest commandline
> strncmp size
>
> Fix minor, and non critical, copy and past
> -Original Message-
> From: Wu, Jingjing
> Sent: Tuesday, November 10, 2015 3:11 AM
> To: dev at dpdk.org
> Cc: Wu, Jingjing; Zhang, Helin; Chilikin, Andrey
> Subject: [PATCH] doc: announce ABI change for struct rte_eth_fdir_flow
>
> Signed-off-by: Jingj
I would suggest rearranging members of rte_eth_fdir_tunnel_type to set
RTE_FDIR_TUNNEL_TYPE_UNKNOWN=0 so any global/static variables or variables
after memset(0) would have unknown type.
Regards,
Andrey
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Wenzh
> -Original Message-
> From: Richardson, Bruce
> Sent: Tuesday, September 29, 2015 3:38 PM
> To: Chilikin, Andrey
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 1/3] librte_ether: add RTE_ETH_FDIR_OTHER
> for flow director behavior
>
> On Tue, Sep 2
Hi Vinod,
Could you provide more information or probably an example of any "non-standard"
packets?
Regards,
Andrey
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Krishna, Vinod
Sent: Thursday, September 24, 2015 12:55 PM
To: dev at dpdk.org
Subject: [dpdk-dev] R
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Neil Horman
> Sent: Thursday, June 4, 2015 2:56 PM
> To: Wiles, Keith
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [RFC PATCH] eal:Add new API for parsing args at
> rte_eal_init time
>
> On Thu, Jun 04, 2015
> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Wednesday, June 3, 2015 9:17 AM
> To: Chilikin, Andrey
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] examples: add ip version check for l3fwd app
>
> 2015-05-1
should take into account hash key?s
length as well.
Regards,
Andrey
From: Vladimir Medvedkin [mailto:medvedk...@gmail.com]
Sent: Thursday, May 7, 2015 11:28 AM
To: Chilikin, Andrey
Cc: dev at dpdk.org
Subject: Re: [dpdk-dev] [PATCH v2] Add toeplitz hash algorithm used by RSS
Hi Andrey,
The main
Hi Vladimir,
Why limit Toeplitz hash calculation to predefined tuples and length? Should it
be more general, something like
rte_softrss_be(void *input, uint32_t input_len, const uint8_t *rss_key) to
enable hash calculation for an input of any size? It would be useful for
distributing packets us
Hi Helin,
I would agree with Konstantin about new naming for VLAN tags. I think we can
leave existing name for t vlan_tci and just name new VLAN tag differently. I
was thinking in the line of "vlan_tci_outer" or "stag_tci". So vlan_tci will
store single VLAN in case if only one L2 tag is presen
> -Original Message-
> From: Zhang, Helin
> Sent: Wednesday, March 4, 2015 8:34 AM
> To: Chilikin, Andrey; dev at dpdk.org
> Subject: RE: [dpdk-dev] [PATCH v4 01/18] mbuf: redefinition of packet_type
> in rte_mbuf
>
>
>
> > -Original Message-
&g
Hi Helin,
I see that you have removed "uint16_t reserved" member from rte_mbuf:
> + uint16_t data_len;/**< Amount of data in segment buffer. */
> uint16_t vlan_tci;/**< VLAN Tag Control Identifier (CPU order)
> */
> - uint16_t reserved;
> union {
>
Me bad, missed wrapping union :)
Thanks,
Andrey
-Original Message-
From: Ananyev, Konstantin
Sent: Friday, November 21, 2014 7:35 PM
To: Chilikin, Andrey; Wu, Jingjing; dev at dpdk.org
Subject: RE: [dpdk-dev] [PATCH v6 09/22] mbuf: extend fdir field
Hi Andrey,
> -Original Mess
This patch adds extra 32bits to rte_mbuf::hash - so 'uint32_t usr' will move to
the second cache line?
Regards,
Andrey
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Jingjing Wu
Sent: Friday, November 21, 2014 12:47 AM
To: dev at dpdk.org
Subject: [dpdk-dev] [PAT
, November 14, 2014 5:21 PM
To: Chilikin, Andrey; Ananyev, Konstantin; Kamraan Nasim; dev at dpdk.org
Cc: Yuanzhang Hu; Zhang, Helin
Subject: Re: [dpdk-dev] Load-balancing position field in DPDK load_balancer
sample app vs. Hash table
Thank you. And one more thing, does Fortville (or Niantic) support
Fortville supports symmetrical hashing on HW level, a patch for i40e PMD was
submitted a couple of weeks ago. For Niantic you can use symmetrical rss key
recommended by Konstantin.
Regards,
Andrey
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Ananyev, Konstant
For me these defines make perfect sense - tunnelling filters require
combinations of different tunnel components, but not all combinations are
valid. So defining valid combinations separately helps.
Regards,
Andrey
> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at
Hi Helin,
Should we define packet classification types separately and do not reuse bit
shifts for RSS register as pctypes?
Packet classification is a global index table which used by RSS Hash Enable
registers, not vice versa.
For example, there is no Packet classification named
"ETH_RSS_NONF_IP
45 matches
Mail list logo
