[dpdk-dev] [PATCH] ixgbe: support flow director for X540

[Thomas Monjalon]

From: Mauro Annarumma 

Flow director in X540 uses the same registers as in 82599.
So it just has to be enabled in the 82599 implementation.

Signed-off-by: Mauro Annarumma 
---
 lib/librte_pmd_ixgbe/ixgbe_fdir.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/lib/librte_pmd_ixgbe/ixgbe_fdir.c 
b/lib/librte_pmd_ixgbe/ixgbe_fdir.c
index f15151a..0d91ff9 100644
--- a/lib/librte_pmd_ixgbe/ixgbe_fdir.c
+++ b/lib/librte_pmd_ixgbe/ixgbe_fdir.c
@@ -182,7 +182,7 @@ ixgbe_fdir_configure(struct rte_eth_dev *dev)

PMD_INIT_FUNC_TRACE();

-   if (hw->mac.type != ixgbe_mac_82599EB)
+   if (hw->mac.type != ixgbe_mac_82599EB && hw->mac.type !=ixgbe_mac_X540)
return -ENOSYS;

err = configure_fdir_flags(>data->dev_conf.fdir_conf, );
@@ -464,7 +464,7 @@ fdir_add_update_signature_filter(struct rte_eth_dev *dev,
union ixgbe_atr_input input;
int err;

-   if (hw->mac.type != ixgbe_mac_82599EB)
+   if (hw->mac.type != ixgbe_mac_82599EB && hw->mac.type !=ixgbe_mac_X540)
return -ENOSYS;

err = fdir_filter_to_atr_input(fdir_filter, );
@@ -550,7 +550,7 @@ ixgbe_fdir_remove_signature_filter(struct rte_eth_dev *dev,

PMD_INIT_FUNC_TRACE();

-   if (hw->mac.type != ixgbe_mac_82599EB)
+   if (hw->mac.type != ixgbe_mac_82599EB && hw->mac.type !=ixgbe_mac_X540)
return -ENOSYS;

err = fdir_filter_to_atr_input(fdir_filter, );
@@ -674,7 +674,7 @@ ixgbe_fdir_set_masks(struct rte_eth_dev *dev, struct 
rte_fdir_masks *fdir_masks)

hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);

-   if (hw->mac.type != ixgbe_mac_82599EB)
+   if (hw->mac.type != ixgbe_mac_82599EB && hw->mac.type !=ixgbe_mac_X540)
return -ENOSYS;

err = ixgbe_reinit_fdir_tables_82599(hw);
@@ -784,7 +784,7 @@ fdir_add_update_perfect_filter(struct rte_eth_dev *dev,
union ixgbe_atr_input input;
int err;

-   if (hw->mac.type != ixgbe_mac_82599EB)
+   if (hw->mac.type != ixgbe_mac_82599EB && hw->mac.type !=ixgbe_mac_X540)
return -ENOSYS;

err = fdir_filter_to_atr_input(fdir_filter, );
@@ -836,7 +836,7 @@ ixgbe_fdir_remove_perfect_filter(struct rte_eth_dev *dev,

PMD_INIT_FUNC_TRACE();

-   if (hw->mac.type != ixgbe_mac_82599EB)
+   if (hw->mac.type != ixgbe_mac_82599EB && hw->mac.type !=ixgbe_mac_X540)
return -ENOSYS;

err = fdir_filter_to_atr_input(fdir_filter, );
@@ -859,7 +859,7 @@ ixgbe_fdir_info_get(struct rte_eth_dev *dev, struct 
rte_eth_fdir *fdir)
IXGBE_DEV_PRIVATE_TO_FDIR_INFO(dev->data->dev_private);
uint32_t reg;

-   if (hw->mac.type != ixgbe_mac_82599EB)
+   if (hw->mac.type != ixgbe_mac_82599EB && hw->mac.type !=ixgbe_mac_X540)
return;

/* Get the information from registers */
-- 
1.9.0

[dpdk-dev] [PATCH 5/6] xen: dont create dependency on cmdline library

[Thomas Monjalon]

07/03/2014 10:13, Stephen Hemminger:
> The driver should not introduce an unnecessary dependency on the cmdline
> code. We don't build that code since it is not used in our product.

Your product is not the concern but I agree this dependency is unnecessary.
I'd just remove the comment about your product.

> +/* defined in  but that has conflicts with rte_ethdev.h */
> +extern struct ether_addr *ether_aton(const char *);

It seems we should fix this conflict first.
I think the problem is about libc redefinitions in rte_ether.h.
Patches are welcome.

-- 
Thomas

[dpdk-dev] [PATCH 2/6] qos: use rte_zmalloc instead of memzone for allocation

[Thomas Monjalon]

07/03/2014 10:13, Stephen Hemminger:
> Memory zone's are inflexible and can not be destroyed.
> The size is fixed when initially created therefor QoS parameters
> could not be modified at run time, because table size for a subport
> might change.
> 
> Signed-off-by: Stephen Hemminger 

This change would probably deserve a description of the use case.
Please explain in the log and/or comments why you need to increase this size.

-- 
Thomas

[dpdk-dev] [PATCH 4/6] mempool: use GCC push/pop

[Thomas Monjalon]

07/03/2014 10:13, Stephen Hemminger:
> The include file should not change the GCC compile options for
> the whole file being compiled, but only for the one inline function
> that needs it. Using the push_options/pop_options fixes this.
> 
> Signed-off-by: Stephen Hemminger 

Acked and applied for version 1.6.0r2.

Thank you
-- 
Thomas

[dpdk-dev] [PATCH 3/6] rte_jhash: make arg to rte_jhash2 const

[Thomas Monjalon]

07/03/2014 10:13, Stephen Hemminger:
> The argument to rte_jhash2() is not changed.
> 
> Signed-off-by: Stephen Hemminger 

Acked and applied for version 1.6.0r2.

Thank you
-- 
Thomas

[dpdk-dev] [PATCH 1/6] rte_mbuf: copy offload flags when doing attach/clone of mbuf

[Thomas Monjalon]

07/03/2014 10:13, Stephen Hemminger:
> rte_pktmbuf_attach copies the packet meta data but does not
> copy the offload flags. This means that cloned packets lose
> their offload settings such as vlan tag.
> 
> Signed-off-by: Stephen Hemminger 

Acked and applied for version 1.6.0r2.

Thank you
-- 
Thomas

[dpdk-dev] VM L2 control register (PFVML2FLT) configuring in VMDQ mode

[Vladimir Medvedkin]

Hi all,

I found that there is no way to configure pool behavior, for example accept
broadcasts, in  VMDQ mode. For SR-IOV there is rte_eth_dev_set_vf_rxmode(),
but according to datasheet it doesn't matter whether the 82599's virtual
environment operates in IOV mode or in Next Generation VMDq mode.

So, we have 2 paths: either make single function by removing from
rte_eth_dev_set_vf_rxmode()
checking pool(or vf) number against dev_info.max_vfs
or make similar function for vmdq mode.

What is the best?

[dpdk-dev] [dpdk-announce] SPEED MATTERS contest by 6WIND

[Thomas Monjalon]

Hello all,

This is the first day of the first DPDK contest!

Developers, Network Engineers, Academics
Invited To Enter Network Tool Implementation Contest

6WIND, a developer of packet processing software, is inviting the public at 
large to enter a software development contest, called "SPEED MATTERS: The 
Challenge", which will reward creativity, execution and planning for savvy 
technology professionals.

"The objective of our contest is for applicants to enter novel applications 
that have been designed using Intel DPDK. Entries can take multiple forms 
including white papers, proof-of-concepts and finished products. We believe 
that by sharing implementation examples, we can increase the knowledge of the 
broader community to lend expertise in building high-performance networking 
applications with Linux."

Winners of "SPEED MATTERS: The Challenge" will be announced via 6WIND at Hot 
Interconnects in Google?s Mountain View Headquarters on August 19, 2014.

More information: http://6wind.com/speed-matters-information

[dpdk-dev] [memnic PATCH 3/5] pmd: implement stats of MEMNIC

[Thomas Monjalon]

Hi,

11/03/2014 05:38, Hiroshi Shimamoto:
> From: Hiroshi Shimamoto 
> 
> Implement missing feature to account statistics.
> This patch adds just an infrastructure.
> 
> Signed-off-by: Hiroshi Shimamoto 
> Reviewed-by: Hayato Momma 

[...]

> @@ -51,6 +51,7 @@ struct memnic_adapter {
>   int up_idx, down_idx;
>   struct rte_mempool *mp;
>   struct ether_addr mac_addr;
> + struct rte_eth_stats stats[RTE_MAX_LCORE];
>  };

Could you make a comment to explain why you allocate a structure per core?
It is easier to read when locking strategy is described.

> + for (i = 0; i < RTE_MAX_LCORE; i++) {
> + struct rte_eth_stats *st = >stats[i];
> +
> + memset(st, 0, sizeof(*st));
> + }

Could you use only one memset for the array?

-- 
Thomas

[dpdk-dev] [PATCH v3] eal_common_cpuflags: Fix %rbx corruption, and simplify the code

[Neil Horman]

On Mon, Mar 24, 2014 at 11:09:52AM -0700, H. Peter Anvin wrote:
> On 03/24/2014 10:44 AM, Neil Horman wrote:
> > * Modified cpuid_reg enum to start at 1 rather than zero
> > * Added CPUID_REG macro to drop enum value by 1 during access
> 
> I guess I don't get it... why?
> 
To add an extra sanity check in rte_get_flag_enabled.  If we were moving to the
use of C99 initalizers, I wanted something to catch the possibility that we skip
a flag by accident (i.e. leave a zero initalized hole in the array).  Except 0
from my read is a valid value for all the fields of the array.  So I bumped up
the cpuid register enum by one and wrapped it in a macro.  That way we can test
for !feat->reg as an indicator that we're requesting feature support for a flag
thats not listed in the array.
Neil

>   -hpa
> 
> 

[dpdk-dev] [PATCH v3] eal_common_cpuflags: Fix %rbx corruption, and simplify the code

[H. Peter Anvin]

On 03/24/2014 12:52 PM, Neil Horman wrote:
>>
> To add an extra sanity check in rte_get_flag_enabled.  If we were moving to 
> the
> use of C99 initalizers, I wanted something to catch the possibility that we 
> skip
> a flag by accident (i.e. leave a zero initalized hole in the array).  Except 0
> from my read is a valid value for all the fields of the array.  So I bumped up
> the cpuid register enum by one and wrapped it in a macro.  That way we can 
> test
> for !feat->reg as an indicator that we're requesting feature support for a 
> flag
> thats not listed in the array.

It actually isn't: there aren't any flags in CPUID leaf 0, so since the
code only looks for bits it'd be perfectly okay to reject leaf 0.

Another thing that I noted is that the code doesn't actually check that
any particular leaf is valid (by checking the maximum leaf number in
CPUID leaf 0x:EAX).  Especially for the leaf 7 features this
could result in false positives, which obviously would be disastrous.

-hpa

[dpdk-dev] [PATCH v3] eal_common_cpuflags: Fix %rbx corruption, and simplify the code

[Neil Horman]

Neil Horman reported that on x86-64 the upper half of %rbx would get
clobbered when the code was compiled PIC or PIE, because the
i386-specific code to preserve %ebx was incorrectly compiled.

However, the code is really way more complex than it needs to be.  For
one thing, the CPUID instruction only needs %eax (leaf) and %ecx
(subleaf) as parameters, and since we are testing for bits, we might
as well list the bits explicitly.  Furthermore, we can use an array
rather than doing a switch statement inside a structure.

Reported-by: Neil Horman 
Signed-off-by: H. Peter Anvin 
Signed-off-by: Neil Horman 

---
Change notes:
v2) Corrected build errors
Fixed cpuid_register_t reference passing
Fixed typedef name typo

v3)
* Modified feature_entry struct to drop the name field, as its unused
* Modified cpu_feature_table to use C99 initalizers
* Updated FEAT_DEF macro to include all feature_entry fields
* Modified cpuid_reg enum to start at 1 rather than zero
* Added CPUID_REG macro to drop enum value by 1 during access
* Added check on feat->reg use to detect missing entries
* Fixed a bug in rte_cpu_check_supported in which negative errors are ignored
---
 lib/librte_eal/common/eal_common_cpuflags.c | 281 +---
 1 file changed, 134 insertions(+), 147 deletions(-)

diff --git a/lib/librte_eal/common/eal_common_cpuflags.c 
b/lib/librte_eal/common/eal_common_cpuflags.c
index 1ebf78c..9ee0490 100644
--- a/lib/librte_eal/common/eal_common_cpuflags.c
+++ b/lib/librte_eal/common/eal_common_cpuflags.c
@@ -53,22 +53,15 @@
  * Enumeration of CPU registers
  */
 enum cpu_register_t {
-   REG_EAX = 0,
-   REG_EBX,
+   REG_EAX = 1,
REG_ECX,
REG_EDX,
+   REG_EBX,
 };

-/**
- * Parameters for CPUID instruction
- */
-struct cpuid_parameters_t {
-   uint32_t eax;
-   uint32_t ebx;
-   uint32_t ecx;
-   uint32_t edx;
-   enum cpu_register_t return_register;
-};
+#define CPUID_REG(reg) (reg - 1)
+
+typedef uint32_t cpuid_registers_t[4];

 #define CPU_FLAG_NAME_MAX_LEN 64

@@ -76,109 +69,111 @@ struct cpuid_parameters_t {
  * Struct to hold a processor feature entry
  */
 struct feature_entry {
-   enum rte_cpu_flag_t feature;/**< feature name */
+   uint32_t leaf;  /**< cpuid leaf */
+   uint32_t subleaf;   /**< cpuid subleaf */
+   uint32_t reg;   /**< cpuid register */
+   uint32_t bit;   /**< cpuid register bit */
char name[CPU_FLAG_NAME_MAX_LEN];   /**< String for printing */
-   struct cpuid_parameters_t params;   /**< cpuid parameters */
-   uint32_t feature_mask;  /**< bitmask for feature */
 };

-#define FEAT_DEF(f) RTE_CPUFLAG_##f, #f
+#define FEAT_DEF(name, leaf, subleaf, reg, bit) \
+   [RTE_CPUFLAG_##name] = {leaf, subleaf, reg, bit, #name },

 /**
  * An array that holds feature entries
  */
 static const struct feature_entry cpu_feature_table[] = {
-   {FEAT_DEF(SSE3),  {0x1, 0, 0, 0, REG_ECX}, 0x0001},
-   {FEAT_DEF(PCLMULQDQ), {0x1, 0, 0, 0, REG_ECX}, 0x0002},
-   {FEAT_DEF(DTES64),{0x1, 0, 0, 0, REG_ECX}, 0x0004},
-   {FEAT_DEF(MONITOR),   {0x1, 0, 0, 0, REG_ECX}, 0x0008},
-   {FEAT_DEF(DS_CPL),{0x1, 0, 0, 0, REG_ECX}, 0x0010},
-   {FEAT_DEF(VMX),   {0x1, 0, 0, 0, REG_ECX}, 0x0020},
-   {FEAT_DEF(SMX),   {0x1, 0, 0, 0, REG_ECX}, 0x0040},
-   {FEAT_DEF(EIST),  {0x1, 0, 0, 0, REG_ECX}, 0x0080},
-   {FEAT_DEF(TM2),   {0x1, 0, 0, 0, REG_ECX}, 0x0100},
-   {FEAT_DEF(SSSE3), {0x1, 0, 0, 0, REG_ECX}, 0x0200},
-   {FEAT_DEF(CNXT_ID),   {0x1, 0, 0, 0, REG_ECX}, 0x0400},
-   {FEAT_DEF(FMA),   {0x1, 0, 0, 0, REG_ECX}, 0x1000},
-   {FEAT_DEF(CMPXCHG16B),{0x1, 0, 0, 0, REG_ECX}, 0x2000},
-   {FEAT_DEF(XTPR),  {0x1, 0, 0, 0, REG_ECX}, 0x4000},
-   {FEAT_DEF(PDCM),  {0x1, 0, 0, 0, REG_ECX}, 0x8000},
-   {FEAT_DEF(PCID),  {0x1, 0, 0, 0, REG_ECX}, 0x0002},
-   {FEAT_DEF(DCA),   {0x1, 0, 0, 0, REG_ECX}, 0x0004},
-   {FEAT_DEF(SSE4_1),{0x1, 0, 0, 0, REG_ECX}, 0x0008},
-   {FEAT_DEF(SSE4_2),{0x1, 0, 0, 0, REG_ECX}, 0x0010},
-   {FEAT_DEF(X2APIC),{0x1, 0, 0, 0, REG_ECX}, 0x0020},
-   {FEAT_DEF(MOVBE), {0x1, 0, 0, 0, REG_ECX}, 0x0040},
-   {FEAT_DEF(POPCNT),{0x1, 0, 0, 0, REG_ECX}, 0x0080},
-   {FEAT_DEF(TSC_DEADLINE),  {0x1, 0, 0, 0, REG_ECX}, 0x0100},
-   {FEAT_DEF(AES),   {0x1, 0, 0, 0, REG_ECX}, 0x0200},
-   {FEAT_DEF(XSAVE), {0x1, 0, 0, 0, REG_ECX}, 0x0400},
-   {FEAT_DEF(OSXSAVE),   {0x1, 0, 0, 0, REG_ECX}, 

[dpdk-dev] [PATCH v2] eal_common_cpuflags: Fix %rbx corruption, and simplify the code

[Thomas Monjalon]

21/03/2014 13:48, Neil Horman:
> On Fri, Mar 21, 2014 at 08:03:34AM -0700, H. Peter Anvin wrote:
> > On 03/21/2014 07:49 AM, Neil Horman wrote:
> > > From: "H. Peter Anvin" 
> > > 
> > > Neil Horman reported that on x86-64 the upper half of %rbx would get
> > > clobbered when the code was compiled PIC or PIE, because the
> > > i386-specific code to preserve %ebx was incorrectly compiled.
> > > 
> > > However, the code is really way more complex than it needs to be.  For
> > > one thing, the CPUID instruction only needs %eax (leaf) and %ecx
> > > (subleaf) as parameters, and since we are testing for bits, we might
> > > as well list the bits explicitly.  Furthermore, we can use an array
> > > rather than doing a switch statement inside a structure.
> > > 
> > > Reported-by: Neil Horman 
> > > Signed-off-by: H. Peter Anvin 
> > > Tested-by: Neil Horman 
> > 
> > Thank you for dealing with this!
> > 
> > On the subject of my other email... are C99 initializers acceptable in
> > dpdk?  If so, I think making that change, too, would be a good idea.
> 
> I'll have to defer this to others, I'm not sure what the accepted
> initalization method is.  I'm guessing their fine, as both icc and gcc
> allow them and those are the supported compilers for dpdk, but I'd like to
> hear someone in the maintainership comment.

Yes, DPDK use C99 syntax.
Feel free to use it in a v3 :)

-- 
Thomas

[dpdk-dev] [RFC UNTESTED PATCH] eal_common_cpuflags: Fix %rbx corruption, and simplify the code

[Neil Horman]

On Thu, Mar 20, 2014 at 10:03:53AM -0700, H. Peter Anvin wrote:
> I just realized there is yet another oddity in this code:
> 
> > @@ -78,8 +69,10 @@ struct cpuid_parameters_t {
> >  struct feature_entry {
> > enum rte_cpu_flag_t feature;/**< feature name */
> 
> The structure contains a field with an enum value...
> 
> > char name[CPU_FLAG_NAME_MAX_LEN];   /**< String for printing */
> > -   struct cpuid_parameters_t params;   /**< cpuid parameters */
> > -   uint32_t feature_mask;  /**< bitmask for feature */
> > +   uint32_t leaf;  /**< cpuid leaf */
> > +   uint32_t subleaf;   /**< cpuid subleaf */
> > +   uint32_t reg;   /**< cpuid register */
> > +   uint32_t bit;   /**< cpuid register bit */
> >  };
> >  
> >  
> >  /*
> > @@ -240,17 +207,20 @@ rte_cpu_get_features(struct cpuid_parameters_t params)
> >  int
> >  rte_cpu_get_flag_enabled(enum rte_cpu_flag_t feature)
> >  {
> > -   int value;
> > +   const struct feature_entry *feat;
> > +   cpu_registers_t regs;
> >  
> > if (feature >= RTE_CPUFLAG_NUMFLAGS)
> > /* Flag does not match anything in the feature tables */
> > return -ENOENT;
> >  
> > -   /* get value of the register containing the desired feature */
> > -   value = rte_cpu_get_features(cpu_feature_table[feature].params);
> > +   feat = _feature_table[feature];
> > +
> > +   /* get the cpuid leaf containing the desired feature */
> > +   rte_cpu_get_features(feat->leaf, feat->subleaf, );
> >  
> > /* check if the feature is enabled */
> > -   return (cpu_feature_table[feature].feature_mask & value) > 0;
> > +   return (regs[feat->reg] >> feat->bit) & 1;
> >  }
> >  
> >  /**
> 
> ... however, this field is never actually accessed *anywhere* in the
> code; the code instead uses the enum value as the table index. There is
> absolutely no enforcement that the table contents is aligned with the enum.
> 
> If C99-style initializers are permitted in this codebase, I would
> strongly recommend using them, and then drop the enum field in struct
> feature_entry and use a macro such as:
> 
Actually, its a bit simpler than that, the enum parameter is actually completely
unused, and so can be removed entirely.  The FEAT_DEF macro does what you
suggest below already, but only for the feature and name fields.

I'll remove the enum and its definition, and augment the macro to cover the rest
of the fields.

Neil

> #define FEAT(name,leaf,subleaf,reg,bit) \
>   [RTE_CPUFLAG_##f] = { leaf, subleaf, reg, bit, #f },
> 
> (I'd move the string to the end, but that is just a microoptimization.
> I'm kind of OCD that way.)
> 
>   -hpa
> 
> 

[dpdk-dev] [PATCH v3] eal_common_cpuflags: Fix %rbx corruption, and simplify the code

[H. Peter Anvin]

On 03/24/2014 10:44 AM, Neil Horman wrote:
> * Modified cpuid_reg enum to start at 1 rather than zero
> * Added CPUID_REG macro to drop enum value by 1 during access

I guess I don't get it... why?

-hpa

[dpdk-dev] Achieve maximum transmit rate

[sabu kurian]

Hello Friends,

What should be done to achieve maximum packet transfer rate using Intel
DPDK...? What are the things I should tune ? Does having more no.of tx
descriptors help ?
With a burst size of 30 and having 512 tx descriptors , I get a speed of
around one hundred thousand packets per second (74 byte packets). What are
the ones that really affect the transmit rate ? I tried changing the burst
size, but the speed decreased as I increased the burst size to some 500
(with 1024 tx descriptors).

Thanks and regards