[dpdk-dev] [PATCH] fm10k: fix switch manager high CPU usage
Hi Mark, > -Original Message- > From: Chen, Jing D > Sent: Wednesday, February 03, 2016 3:23 PM > To: He, Shaopeng; dev at dpdk.org > Cc: Wang, Xiao W > Subject: RE: [PATCH] fm10k: fix switch manager high CPU usage > > Hi, > > > Best Regards, > Mark > > > > -Original Message- > > From: He, Shaopeng > > Sent: Thursday, January 28, 2016 1:47 PM > > To: dev at dpdk.org > > Cc: Chen, Jing D; Wang, Xiao W; He, Shaopeng > > Subject: [PATCH] fm10k: fix switch manager high CPU usage > > > > fm10k switch core uses source MAC + VID + SGLORT to do look up in MAC > > table. If no match, an exception interrupt will be sent to the switch > > manager, and cause high CPU usage. > > Above paragraph didn't describe the bug clearly. Can you add more Words on > it? Thanks for the comments, I will send a v2. > > > This patch fixes this issue. A default SGLORT is assigned to each TX > > queue. This default value works for non-VMDq mode and current VMDq > > example. For advanced VMDq usage, e.g. > > different source MAC address for different TX queue, FTAG forwarding > > function could be used to change this default SGLORT value. > > > > Signed-off-by: Shaopeng He > > --- > > drivers/net/fm10k/fm10k_ethdev.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/drivers/net/fm10k/fm10k_ethdev.c > > b/drivers/net/fm10k/fm10k_ethdev.c > > index e4aed94..f6eb05d 100644 > > --- a/drivers/net/fm10k/fm10k_ethdev.c > > +++ b/drivers/net/fm10k/fm10k_ethdev.c > > @@ -675,6 +675,9 @@ fm10k_dev_tx_init(struct rte_eth_dev *dev) > > FM10K_WRITE_REG(hw, FM10K_TDBAH(i), > > base_addr >> (CHAR_BIT * sizeof(uint32_t))); > > FM10K_WRITE_REG(hw, FM10K_TDLEN(i), size); > > + > > + /* assign default SGLORT for each TX queue */ > > + FM10K_WRITE_REG(hw, FM10K_TX_SGLORT(i), hw- > > >mac.dglort_map); > > } > > > > /* set up vector or scalar TX function as appropriate */ > > -- > > 1.9.3
[dpdk-dev] [PATCH] fm10k: enable PCIe port level Loopback Suppression
Hi Mark, > -Original Message- > From: Chen, Jing D > Sent: Wednesday, February 03, 2016 3:18 PM > To: He, Shaopeng; dev at dpdk.org > Cc: Wang, Xiao W > Subject: RE: [PATCH] fm10k: enable PCIe port level Loopback Suppression > > Hi, > > Best Regards, > Mark > > > > -Original Message- > > From: He, Shaopeng > > Sent: Thursday, January 28, 2016 1:49 PM > > To: dev at dpdk.org > > Cc: Chen, Jing D; Wang, Xiao W; He, Shaopeng > > Subject: [PATCH] fm10k: enable PCIe port level Loopback Suppression > > > > A PCIe port may represent within it multiple logical ports > > (for example when SR-IOV is enabled, or when a VMDQ type logical > > port scheme is employed assigning ports to sets of queues). > > For this reason each RX queue in each PCIe port is given a source > > GLORT that is used for loopback suppression. > > This patch assigns a SGLORT for each RX queue, and enables PCIe > > port level Loopback Suppression. > > > > The log message is a little obscure for me. Maybe you can wrote: > In FM10K, a single PF device can derive out a few logical ports, like SRIOV > VF device, VMDQ object. To better manage them, FM10K silicon assigned a > Unique GLORT ID to each logical ports. > When a logical port sends a broadcast packet, the silicon will flood it to all > Logical ports, including the one sent the broadcast packet. To prevent this, > silicon has a rxq register to fill the glort id of the logical port that > queue binds > to Thanks for the suggestion, I will reword and send another version. Thanks, --Shaopeng > > > Signed-off-by: Shaopeng He > > --- > > drivers/net/fm10k/fm10k_ethdev.c | 18 +- > > 1 file changed, 17 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/net/fm10k/fm10k_ethdev.c > > b/drivers/net/fm10k/fm10k_ethdev.c > > index f6eb05d..60f821a 100644 > > --- a/drivers/net/fm10k/fm10k_ethdev.c > > +++ b/drivers/net/fm10k/fm10k_ethdev.c > > @@ -690,12 +690,15 @@ static int > > fm10k_dev_rx_init(struct rte_eth_dev *dev)
[dpdk-dev] [PATCH v2] i40e: fix vlan filtering
> -Original Message-
> From: Julien Meunier [mailto:julien.meunier at 6wind.com]
> Sent: Wednesday, February 3, 2016 7:32 PM
> To: Zhang, Helin
> Cc: dev at dpdk.org
> Subject: Re: [PATCH v2] i40e: fix vlan filtering
>
> Hello,
>
> INFO log level is used in order to keep code homogeneity:
> i40e_vsi_config_vlan_stripping or i40e_dev_init_vlan use this log level during
> failure for example.
>
> Tell me if ERR log level for VLAN filtering issue must be set.
There is a failure, and may result in uncertain behaviors which cannot be
ignored.
I'd suggest to use ERR but not INFO, though I am not so confident on that.
Could Thomas help give some guidance on that?
Regards,
Helin
>
> On 02/03/2016 02:15 AM, Zhang, Helin wrote:
> >
> >> -Original Message-
> >> From: Julien Meunier [mailto:julien.meunier at 6wind.com]
> >> Sent: Tuesday, February 2, 2016 9:51 PM
> >> To: Zhang, Helin
> >> Cc: dev at dpdk.org
> >> Subject: [PATCH v2] i40e: fix vlan filtering
> >>
> >> VLAN filtering was always performed, even if hw_vlan_filter was disabled.
> >> During device initialization, default filter
> >> RTE_MACVLAN_PERFECT_MATCH was applied. In this situation, all
> >> incoming VLAN frames were dropped by the card (increase of the register
> RUPP - Rx Unsupported Protocol).
> >>
> >> In order to restore default behavior, if HW VLAN filtering is
> >> activated, set a filter to match MAC and VLAN. If not, set a filter to only
> match MAC.
> >>
> >> Signed-off-by: Julien Meunier
> >> ---
> >> Changes since v1:
> >> - use ether_addr_copy() for mac copy
> >> - add more debug messages in case of failure
> >> - update all existing filters when multiple mac addresses have been
> >> configured
> >> - when adding new mac address, use correct filter
> >>
> >> TODO:
> >> - i40e_update_default_filter_setting always forces to
> >>RTE_MACVLAN_PERFECT_MATCH.
> >>=> The type of filter should be changed according to vlan filter
> >> setting.
> >>
> >> - What happens if vlan filter setting changes when various filters are
> >> already
> >>set like RTE_MACVLAN_PERFECT_MATCH,
> RTE_MACVLAN_PERFECT_MATCH,
> >>RTE_MAC_HASH_MATCH, RTE_MACVLAN_HASH_MATCH ?
> >>=> With testpmd, it is possible to add manually these filters. But when
> >>changing vlan filter setting, all previous filter set manually are
> overriden.
> >> ---
> >> drivers/net/i40e/i40e_ethdev.c | 73
> >> --
> >> drivers/net/i40e/i40e_ethdev.h | 1 +
> >> 2 files changed, 72 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/net/i40e/i40e_ethdev.c
> >> b/drivers/net/i40e/i40e_ethdev.c index bf6220d..64d6ada 100644
> >> --- a/drivers/net/i40e/i40e_ethdev.c
> >> +++ b/drivers/net/i40e/i40e_ethdev.c
> >> @@ -2332,6 +2332,13 @@ i40e_vlan_offload_set(struct rte_eth_dev *dev,
> >> int
> >> mask)
> >>struct i40e_pf *pf =
> I40E_DEV_PRIVATE_TO_PF(dev->data->dev_private);
> >>struct i40e_vsi *vsi = pf->main_vsi;
> >>
> >> + if (mask & ETH_VLAN_FILTER_MASK) {
> >> + if (dev->data->dev_conf.rxmode.hw_vlan_filter)
> >> + i40e_vsi_config_vlan_filter(vsi, TRUE);
> >> + else
> >> + i40e_vsi_config_vlan_filter(vsi, FALSE);
> >> + }
> >> +
> >>if (mask & ETH_VLAN_STRIP_MASK) {
> >>/* Enable or disable VLAN stripping */
> >>if (dev->data->dev_conf.rxmode.hw_vlan_strip)
> >> @@ -2583,7 +2590,10 @@ i40e_macaddr_add(struct rte_eth_dev *dev,
> >>}
> >>
> >>(void)rte_memcpy(&mac_filter.mac_addr, mac_addr,
> ETHER_ADDR_LEN);
> >> - mac_filter.filter_type = RTE_MACVLAN_PERFECT_MATCH;
> >> + if (dev->data->dev_conf.rxmode.hw_vlan_filter)
> >> + mac_filter.filter_type = RTE_MACVLAN_PERFECT_MATCH;
> >> + else
> >> + mac_filter.filter_type = RTE_MAC_PERFECT_MATCH;
> >>
> >>if (pool == 0)
> >>vsi = pf->main_vsi;
> >> @@ -4156,6 +4166,63 @@ fail_mem:
> >>return NULL;
> >> }
> >>
> >> +/* Configure vlan filter on or off */ int
> >> +i40e_vsi_config_vlan_filter(struct i40e_vsi *vsi, bool on) {
> >> + int i, num;
> >> + struct i40e_mac_filter *f;
> >> + struct i40e_mac_filter_info *mac_filter;
> >> + enum rte_mac_filter_type desired_filter;
> >> + int ret = I40E_SUCCESS;
> >> +
> >> + if (on) {
> >> + /* Filter to match MAC and VLAN */
> >> + desired_filter = RTE_MACVLAN_PERFECT_MATCH;
> >> + } else {
> >> + /* Filter to match only MAC */
> >> + desired_filter = RTE_MAC_PERFECT_MATCH;
> >> + }
> >> +
> >> + num = vsi->mac_num;
> >> +
> >> + mac_filter = rte_zmalloc("mac_filter_info_data",
> >> + num * sizeof(*mac_filter), 0);
> >> + if (mac_filter == NULL) {
> >> + PMD_DRV_LOG(ERR, "failed to allocate memory");
> >> + return I40E_ERR_NO_MEMORY;
> >> + }
> >> +
> >> + i = 0;
> >> +
> >> + /* Remove all existing mac */
> >> + TAILQ_FOREACH(f, &vsi->mac_list, next) {
> >> + mac_f
[dpdk-dev] [PATCH 1/2] mbuf: Add rte_pktmbuf_copy
On Wed, 3 Feb 2016 17:23:05 + Olivier MATZ wrote: > +} while ((md = md->next) != NULL); > >> + > >> + *prev = NULL; > > why this? This is null terminating the linked list of segments.
[dpdk-dev] [PATCH] i40e: fix the issue of port initialization failure
> -Original Message- > From: Richardson, Bruce > Sent: Thursday, February 4, 2016 12:31 AM > To: Zhang, Helin > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH] i40e: fix the issue of port initialization > failure > > On Wed, Dec 23, 2015 at 01:32:59PM +0800, Helin Zhang wrote: > > Workaround for the issue of cannot processing adminq commands during > > initialization, when 2x40G or 4x10G is receiving packets in highest > > throughput. Register 0x002698a8 and 0x002698ac should be cleared at > > first, and restored with the default values at the end. No more > > details, as they are not exposed registers. > > > > Signed-off-by: Helin Zhang > > Hi Helin, > > can you please add an appropriately "fixes" line to the patch, since the > subject > explicitly calls it out as a bug-fix. Also, the words "the issue" in the > subject can > be removed as they don't add value. It would also be worthwhile referencing > the adminq in the subject too, since that is the failure being reported. How > about: > > "i40e: fix adminq failure on port init" Oh, sorry, I forgot this patch. Firmware finally fixed it in FVL5, and we need to use new AQ commands for reading/writing some registers. So I will drop this patch. Thanks! Regards, Helin > > Regards, > /Bruce
[dpdk-dev] [PATCH v2] i40e: fix vlan filtering
On Thu, 4 Feb 2016 00:41:00 + "Zhang, Helin" wrote: > > -Original Message- > > From: Julien Meunier [mailto:julien.meunier at 6wind.com] > > Sent: Wednesday, February 3, 2016 7:32 PM > > To: Zhang, Helin > > Cc: dev at dpdk.org > > Subject: Re: [PATCH v2] i40e: fix vlan filtering > > > > Hello, > > > > INFO log level is used in order to keep code homogeneity: > > i40e_vsi_config_vlan_stripping or i40e_dev_init_vlan use this log level > > during > > failure for example. > > > > Tell me if ERR log level for VLAN filtering issue must be set. > There is a failure, and may result in uncertain behaviors which cannot be > ignored. > I'd suggest to use ERR but not INFO, though I am not so confident on that. > Could Thomas help give some guidance on that? Sounds like NOTICE level.
[dpdk-dev] [PATCH v2 1/3] fm10k: enable FTAG based forwarding
Hi Mark,
> -Original Message-
> From: Chen, Jing D
> Sent: Wednesday, February 3, 2016 2:53 PM
> To: Wang, Xiao W
> Cc: dev at dpdk.org; Qiu, Michael ; He, Shaopeng
>
> Subject: RE: [PATCH v2 1/3] fm10k: enable FTAG based forwarding
>
> Hi,
>
> Best Regards,
> Mark
>
>
> > -Original Message-
> > From: Wang, Xiao W
> > Sent: Tuesday, February 02, 2016 6:50 PM
> > To: Chen, Jing D
> > Cc: dev at dpdk.org; Qiu, Michael; He, Shaopeng; Wang, Xiao W
> > Subject: [PATCH v2 1/3] fm10k: enable FTAG based forwarding
> >
> > This patch enables reading sglort info into mbuf for RX and inserting
> > an FTAG at the beginning of the packet for TX. The vlan_tci_outer
> > field selected from rte_mbuf structure for sglort is not used in fm10k now.
> > In FTAG based forwarding mode, the switch will forward packets
> > according to glort info in FTAG rather than mac and vlan table.
> >
> > To activate this feature, user needs to turn
> > ``CONFIG_RTE_LIBRTE_FM10K_FTAG_FWD``
> > to y in common_linuxapp or common_bsdapp. Currently this feature is
> > supported only on PF, because FM10K_PFVTCTL register is read-only for
> > VF.
> >
> > Signed-off-by: Wang Xiao W
> > ---
> > config/common_bsdapp | 1 +
> > config/common_linuxapp | 1 +
> > drivers/net/fm10k/fm10k_ethdev.c | 12
> > drivers/net/fm10k/fm10k_rxtx.c | 17 +
> > drivers/net/fm10k/fm10k_rxtx_vec.c | 9 +
> > 5 files changed, 40 insertions(+)
> >
> > diff --git a/config/common_bsdapp b/config/common_bsdapp index
> > ed7c31c..451f81a 100644
> > --- a/config/common_bsdapp
> > +++ b/config/common_bsdapp
> > @@ -208,6 +208,7 @@ CONFIG_RTE_LIBRTE_FM10K_DEBUG_TX=n
> > CONFIG_RTE_LIBRTE_FM10K_DEBUG_TX_FREE=n
> > CONFIG_RTE_LIBRTE_FM10K_DEBUG_DRIVER=n
> > CONFIG_RTE_LIBRTE_FM10K_RX_OLFLAGS_ENABLE=y
> > +CONFIG_RTE_LIBRTE_FM10K_FTAG_FWD=n
> >
> > #
> > # Compile burst-oriented Mellanox ConnectX-3 (MLX4) PMD diff --git
> > a/config/common_linuxapp b/config/common_linuxapp index
> > 74bc515..c928bce 100644
> > --- a/config/common_linuxapp
> > +++ b/config/common_linuxapp
> > @@ -207,6 +207,7 @@ CONFIG_RTE_LIBRTE_FM10K_DEBUG_TX_FREE=n
> > CONFIG_RTE_LIBRTE_FM10K_DEBUG_DRIVER=n
> > CONFIG_RTE_LIBRTE_FM10K_RX_OLFLAGS_ENABLE=y
> > CONFIG_RTE_LIBRTE_FM10K_INC_VECTOR=y
> > +CONFIG_RTE_LIBRTE_FM10K_FTAG_FWD=n
> >
> > #
> > # Compile burst-oriented Mellanox ConnectX-3 (MLX4) PMD diff --git
> > a/drivers/net/fm10k/fm10k_ethdev.c
> > b/drivers/net/fm10k/fm10k_ethdev.c
> > index e4aed94..3a15c24 100644
> > --- a/drivers/net/fm10k/fm10k_ethdev.c
> > +++ b/drivers/net/fm10k/fm10k_ethdev.c
> > @@ -668,6 +668,18 @@ fm10k_dev_tx_init(struct rte_eth_dev *dev)
> > PMD_INIT_LOG(ERR, "failed to disable queue %d", i);
> > return -1;
> > }
> > +#ifdef RTE_LIBRTE_FM10K_FTAG_FWD
> > + /* Enable use of FTAG bit in TX descriptor, PFVTCTL
> > +* register is read-only for VF.
> > +*/
> > + if (hw->mac.type == fm10k_mac_pf)
> > + FM10K_WRITE_REG(hw, FM10K_PFVTCTL(i),
> > +
> > FM10K_PFVTCTL_FTAG_DESC_ENABLE);
> > + else {
> > + PMD_INIT_LOG(ERR, "FTAG is not supported in
> > VF.\n");
>
> "\n" is not necessary.
Yes, PMD_INIT_LOG has already included a "\n". I will remove it.
>
> > + return -1;
>
> Return "-ENOTSUP"?
>
Yes, "-ENOTSUP" is meaningful, thanks for your comments, I'll fix it in v3.
Best Regards,
Wang Xiao
> > + }
> > +#endif
> >
> > /* set location and size for descriptor ring */
> > FM10K_WRITE_REG(hw, FM10K_TDBAL(i),
[dpdk-dev] [PATCH 1/3] eal/x86: fix build with clang for old AVX
> Subject: [PATCH 1/3] eal/x86: fix build with clang for old AVX
>
> When configuring RTE_MACHINE to "default", rte_memcpy implementation
> is the default one (old AVX).
> In this code, clang raises a warning thanks to -Wsometimes-uninitialized:
>
> rte_memcpy.h:838:6: error:
> variable 'srcofs' is used uninitialized whenever 'if' condition is false
> if (dstofss > 0) {
> ^~~
> rte_memcpy.h:849:6: note: uninitialized use occurs here
> if (srcofs == 0) {
> ^~
>
> It is fixed by initializing srcofs to 0.
>
> Fixes: 1ae817f9f887 ("eal/x86: tune memcpy for platforms without AVX512")
>
> Signed-off-by: Thomas Monjalon
> ---
> lib/librte_eal/common/include/arch/x86/rte_memcpy.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Hi Thomas,
Thanks for pointing this out!
My last hasty modification on this is not correct.
The patch below will fix it. All modifications are tested.
Sorry for all the hassle! :'(
"srcofs" should be calculated based on source address anyway.
--- a/lib/librte_eal/common/include/arch/x86/rte_memcpy.h
+++ b/lib/librte_eal/common/include/arch/x86/rte_memcpy.h
@@ -512,8 +512,9 @@ COPY_BLOCK_64_BACK31:
/**
* Make store aligned when copy size exceeds 512 bytes
*/
- dstofss = 32 - ((uintptr_t)dst & 0x1F);
+ dstofss = (uintptr_t)dst & 0x1F;
if (dstofss > 0) {
+ dstofss = 32 - dstofss;
n -= dstofss;
rte_mov32((uint8_t *)dst, (const uint8_t *)src);
src = (const uint8_t *)src + dstofss;
@@ -834,14 +835,15 @@ COPY_BLOCK_64_BACK15:
* unaligned copy functions require up to 15 bytes
* backwards access.
*/
- dstofss = 16 - ((uintptr_t)dst & 0x0F) + 16;
+ dstofss = (uintptr_t)dst & 0x0F;
if (dstofss > 0) {
+ dstofss = 16 - dstofss + 16;
n -= dstofss;
rte_mov32((uint8_t *)dst, (const uint8_t *)src);
src = (const uint8_t *)src + dstofss;
dst = (uint8_t *)dst + dstofss;
- srcofs = ((uintptr_t)src & 0x0F);
}
+ srcofs = ((uintptr_t)src & 0x0F);
/**
* For aligned copy
[dpdk-dev] [PATCH v3 0/3] fm10k: enable FTAG based forwarding
v3: * Removed "\n" in PMD_INIT_LOG. * Returned "-ENOTSUP" instead of -1 in VF FTAG use case. v2: * Gave an error message for VF FTAG use case. * Added a notice in the doc to emphasize that application should ensure an appropriate FTAG for every frame in FTAG based forwarding mode. Wang Xiao W (3): fm10k: enable FTAG based forwarding doc: add introduction for fm10k FTAG based forwarding doc: update release note for fm10k FTAG support config/common_bsdapp | 1 + config/common_linuxapp | 1 + doc/guides/nics/fm10k.rst| 16 +++- doc/guides/rel_notes/release_2_3.rst | 1 + drivers/net/fm10k/fm10k_ethdev.c | 12 drivers/net/fm10k/fm10k_rxtx.c | 17 + drivers/net/fm10k/fm10k_rxtx_vec.c | 9 + 7 files changed, 56 insertions(+), 1 deletion(-) -- 1.9.3
[dpdk-dev] [PATCH v3 1/3] fm10k: enable FTAG based forwarding
This patch enables reading sglort info into mbuf for RX and inserting
an FTAG at the beginning of the packet for TX. The vlan_tci_outer field
selected from rte_mbuf structure for sglort is not used in fm10k now.
In FTAG based forwarding mode, the switch will forward packets according
to glort info in FTAG rather than mac and vlan table.
To activate this feature, user needs to turn
``CONFIG_RTE_LIBRTE_FM10K_FTAG_FWD``
to y in common_linuxapp or common_bsdapp. Currently this feature is supported
only on PF, because FM10K_PFVTCTL register is read-only for VF.
Signed-off-by: Wang Xiao W
---
config/common_bsdapp | 1 +
config/common_linuxapp | 1 +
drivers/net/fm10k/fm10k_ethdev.c | 12
drivers/net/fm10k/fm10k_rxtx.c | 17 +
drivers/net/fm10k/fm10k_rxtx_vec.c | 9 +
5 files changed, 40 insertions(+)
diff --git a/config/common_bsdapp b/config/common_bsdapp
index ed7c31c..451f81a 100644
--- a/config/common_bsdapp
+++ b/config/common_bsdapp
@@ -208,6 +208,7 @@ CONFIG_RTE_LIBRTE_FM10K_DEBUG_TX=n
CONFIG_RTE_LIBRTE_FM10K_DEBUG_TX_FREE=n
CONFIG_RTE_LIBRTE_FM10K_DEBUG_DRIVER=n
CONFIG_RTE_LIBRTE_FM10K_RX_OLFLAGS_ENABLE=y
+CONFIG_RTE_LIBRTE_FM10K_FTAG_FWD=n
#
# Compile burst-oriented Mellanox ConnectX-3 (MLX4) PMD
diff --git a/config/common_linuxapp b/config/common_linuxapp
index 74bc515..c928bce 100644
--- a/config/common_linuxapp
+++ b/config/common_linuxapp
@@ -207,6 +207,7 @@ CONFIG_RTE_LIBRTE_FM10K_DEBUG_TX_FREE=n
CONFIG_RTE_LIBRTE_FM10K_DEBUG_DRIVER=n
CONFIG_RTE_LIBRTE_FM10K_RX_OLFLAGS_ENABLE=y
CONFIG_RTE_LIBRTE_FM10K_INC_VECTOR=y
+CONFIG_RTE_LIBRTE_FM10K_FTAG_FWD=n
#
# Compile burst-oriented Mellanox ConnectX-3 (MLX4) PMD
diff --git a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_ethdev.c
index e4aed94..65d355e 100644
--- a/drivers/net/fm10k/fm10k_ethdev.c
+++ b/drivers/net/fm10k/fm10k_ethdev.c
@@ -668,6 +668,18 @@ fm10k_dev_tx_init(struct rte_eth_dev *dev)
PMD_INIT_LOG(ERR, "failed to disable queue %d", i);
return -1;
}
+#ifdef RTE_LIBRTE_FM10K_FTAG_FWD
+ /* Enable use of FTAG bit in TX descriptor, PFVTCTL
+* register is read-only for VF.
+*/
+ if (hw->mac.type == fm10k_mac_pf)
+ FM10K_WRITE_REG(hw, FM10K_PFVTCTL(i),
+ FM10K_PFVTCTL_FTAG_DESC_ENABLE);
+ else {
+ PMD_INIT_LOG(ERR, "FTAG is not supported in VF.");
+ return -ENOTSUP;
+ }
+#endif
/* set location and size for descriptor ring */
FM10K_WRITE_REG(hw, FM10K_TDBAL(i),
diff --git a/drivers/net/fm10k/fm10k_rxtx.c b/drivers/net/fm10k/fm10k_rxtx.c
index e958865..f87987d 100644
--- a/drivers/net/fm10k/fm10k_rxtx.c
+++ b/drivers/net/fm10k/fm10k_rxtx.c
@@ -152,6 +152,13 @@ fm10k_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts,
*/
mbuf->ol_flags |= PKT_RX_VLAN_PKT;
mbuf->vlan_tci = desc.w.vlan;
+#ifdef RTE_LIBRTE_FM10K_FTAG_FWD
+ /**
+* mbuf->vlan_tci_outer is an idle field in fm10k driver,
+* so it can be selected to store sglort value.
+*/
+ mbuf->vlan_tci_outer = rte_le_to_cpu_16(desc.w.sglort);
+#endif
rx_pkts[count] = mbuf;
if (++next_dd == q->nb_desc) {
@@ -307,6 +314,13 @@ fm10k_recv_scattered_pkts(void *rx_queue, struct rte_mbuf
**rx_pkts,
*/
mbuf->ol_flags |= PKT_RX_VLAN_PKT;
first_seg->vlan_tci = desc.w.vlan;
+#ifdef RTE_LIBRTE_FM10K_FTAG_FWD
+ /**
+* mbuf->vlan_tci_outer is an idle field in fm10k driver,
+* so it can be selected to store sglort value.
+*/
+ first_seg->vlan_tci_outer = rte_le_to_cpu_16(desc.w.sglort);
+#endif
/* Prefetch data of first segment, if configured to do so. */
rte_packet_prefetch((char *)first_seg->buf_addr +
@@ -432,6 +446,9 @@ static inline void tx_xmit_pkt(struct fm10k_tx_queue *q,
struct rte_mbuf *mb)
q->nb_free -= mb->nb_segs;
q->hw_ring[q->next_free].flags = 0;
+#ifdef RTE_LIBRTE_FM10K_FTAG_FWD
+ q->hw_ring[q->next_free].flags |= FM10K_TXD_FLAG_FTAG;
+#endif
/* set checksum flags on first descriptor of packet. SCTP checksum
* offload is not supported, but we do not explicitly check for this
* case in favor of greatly simplified processing. */
diff --git a/drivers/net/fm10k/fm10k_rxtx_vec.c
b/drivers/net/fm10k/fm10k_rxtx_vec.c
index 2a57eef..0b0f2e3 100644
--- a/drivers/net/fm10k/fm10k_rxtx_vec.c
+++ b/drivers/net/fm10k/fm10k_rxtx_vec.c
@@ -198,7 +198,12 @@ fm10k_rx_vec_condition_check(struct rte_eth_dev *dev)
rxmode->header_split == 1)
return -1
[dpdk-dev] [PATCH v3 2/3] doc: add introduction for fm10k FTAG based forwarding
Add a brief introduction on FTAG, describe what's FTAG and how it works in forwarding. Signed-off-by: Wang Xiao W --- doc/guides/nics/fm10k.rst | 16 +++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/doc/guides/nics/fm10k.rst b/doc/guides/nics/fm10k.rst index 4206b7f..6f61482 100644 --- a/doc/guides/nics/fm10k.rst +++ b/doc/guides/nics/fm10k.rst @@ -1,5 +1,5 @@ .. BSD LICENSE -Copyright(c) 2015 Intel Corporation. All rights reserved. +Copyright(c) 2015-2016 Intel Corporation. All rights reserved. All rights reserved. Redistribution and use in source and binary forms, with or without @@ -34,6 +34,20 @@ FM10K Poll Mode Driver The FM10K poll mode driver library provides support for the Intel FM1 (FM10K) family of 40GbE/100GbE adapters. +FTAG Based Forwarding of FM10K +-- + +FTAG Based Forwarding is a unique feature of FM10K. The FM10K family of NICs +support the addition of a Fabric Tag (FTAG) to carry special information. +The FTAG is placed at the beginning of the frame, it contains information +such as where the packet comes from and goes, and the vlan tag. In FTAG based +forwarding mode, the switch logic forwards packets according to glort (global +resource tag) information, rather than the mac and vlan table. Currently this +feature works only on PF. + +To enable this feature, turn ``CONFIG_RTE_LIBRTE_FM10K_FTAG_FWD`` to y in the +configuration file, and the application should make sure an appropriate FTAG is +inserted for every frame on TX side. Limitations --- -- 1.9.3
[dpdk-dev] [PATCH v3 3/3] doc: update release note for fm10k FTAG support
Update the release note. Signed-off-by: Wang Xiao W --- doc/guides/rel_notes/release_2_3.rst | 1 + 1 file changed, 1 insertion(+) diff --git a/doc/guides/rel_notes/release_2_3.rst b/doc/guides/rel_notes/release_2_3.rst index 7945694..7325230 100644 --- a/doc/guides/rel_notes/release_2_3.rst +++ b/doc/guides/rel_notes/release_2_3.rst @@ -39,6 +39,7 @@ This section should contain new features added in this release. Sample format: Enabled virtio 1.0 support for virtio pmd driver. +* **Added fm10k FTAG based forwarding support.** Resolved Issues --- -- 1.9.3
[dpdk-dev] [PATCH v2] ixgbe: fix link down issue on x550em_x
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Wenzhuo Lu > Sent: Monday, February 01, 2016 4:43 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v2] ixgbe: fix link down issue on x550em_x > > Normally the auto-negotiation is supported by FW. But on > X550EM_X_10G_T it's not supported by FW. As the port of > X550EM_X_10G_T is 10G. If we connect the port with a peer > which is 1G. The link is always down. > We have to supprted auto-neg by SW to avoid such link down > issue. > > Signed-off-by: Wenzhuo Lu Acked-by: Shaopeng He
[dpdk-dev] [PATCH v7 0/2] Add VHOST PMD
The patch introduces a new PMD. This PMD is implemented as thin wrapper of librte_vhost. PATCH v7 changes: - Remove needless parenthesis. - Add release note. - Remove needless line wraps. - Add null pointer check in vring_state_changed(). - Free queue memory in eth_queue_release(). - Fix wrong variable name. - Fix error handling code of eth_dev_vhost_create() and rte_pmd_vhost_devuninit(). - Remove needless null checking from rte_pmd_vhost_devinit/devuninit(). - Use port id to create mac address. - Add doxygen style comments in "rte_eth_vhost.h". - Fix wrong comment in "mk/rte.app.mk". PATCH v6 changes: - Remove rte_vhost_driver_pmd_callback_registe(). - Support link status interrupt. - Support queue state changed interrupt. - Add rte_eth_vhost_get_queue_event(). - Support numa node detection when new device is connected. PATCH v5 changes: - Rebase on latest master. - Fix RX/TX routine to count RX/TX bytes. - Fix RX/TX routine not to count as error packets if enqueue/dequeue cannot send all packets. - Fix if-condition checking for multiqueues. - Add "static" to pthread variable. - Fix format. - Change default behavior not to receive queueing event from driver. - Split the patch to separate rte_eth_vhost_portid2vdev(). PATCH v4 changes: - Rebase on latest DPDK tree. - Fix cording style. - Fix code not to invoke multiple messaging handling threads. - Fix code to handle vdev parameters correctly. - Remove needless cast. - Remove needless if-condition before rt_free(). PATCH v3 changes: - Rebase on latest matser - Specify correct queue_id in RX/TX function. PATCH v2 changes: - Remove a below patch that fixes vhost library. The patch was applied as a separate patch. - vhost: fix crash with multiqueue enabled - Fix typos. (Thanks to Thomas, Monjalon) - Rebase on latest tree with above bernard's patches. PATCH v1 changes: - Support vhost multiple queues. - Rebase on "remove pci driver from vdevs". - Optimize RX/TX functions. - Fix resource leaks. - Fix compile issue. - Add patch to fix vhost library. RFC PATCH v3 changes: - Optimize performance. In RX/TX functions, change code to access only per core data. - Add below API to allow user to use vhost library APIs for a port managed by vhost PMD. There are a few limitations. See "rte_eth_vhost.h". - rte_eth_vhost_portid2vdev() To support this functionality, vhost library is also changed. Anyway, if users doesn't use vhost PMD, can fully use vhost library APIs. - Add code to support vhost multiple queues. Actually, multiple queues functionality is not enabled so far. RFC PATCH v2 changes: - Fix issues reported by checkpatch.pl (Thanks to Stephen Hemminger) Tetsuya Mukawa (2): ethdev: Add a new event type to notify a queue state changed event vhost: Add VHOST PMD config/common_linuxapp | 6 + doc/guides/nics/index.rst | 1 + doc/guides/rel_notes/release_2_3.rst| 3 + drivers/net/Makefile| 4 + drivers/net/vhost/Makefile | 62 ++ drivers/net/vhost/rte_eth_vhost.c | 898 drivers/net/vhost/rte_eth_vhost.h | 109 drivers/net/vhost/rte_pmd_vhost_version.map | 11 + lib/librte_ether/rte_ethdev.h | 2 + mk/rte.app.mk | 6 + 10 files changed, 1102 insertions(+) create mode 100644 drivers/net/vhost/Makefile create mode 100644 drivers/net/vhost/rte_eth_vhost.c create mode 100644 drivers/net/vhost/rte_eth_vhost.h create mode 100644 drivers/net/vhost/rte_pmd_vhost_version.map -- 2.1.4
[dpdk-dev] [PATCH v7 1/2] ethdev: Add a new event type to notify a queue state changed event
This patch adds a below event type.
- RTE_ETH_EVENT_QUEUE_STATE_CHANGE
This event is used for notifying a queue state changed event.
Signed-off-by: Tetsuya Mukawa
---
lib/librte_ether/rte_ethdev.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 8710dd7..2fbf42a 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -2661,6 +2661,8 @@ rte_eth_tx_burst(uint8_t port_id, uint16_t queue_id,
enum rte_eth_event_type {
RTE_ETH_EVENT_UNKNOWN, /**< unknown event type */
RTE_ETH_EVENT_INTR_LSC, /**< lsc interrupt event */
+ RTE_ETH_EVENT_QUEUE_STATE_CHANGE,
+ /**< queue state changed interrupt */
RTE_ETH_EVENT_MAX /**< max value of this enum */
};
--
2.1.4
[dpdk-dev] [PATCH v7 2/2] vhost: Add VHOST PMD
The patch introduces a new PMD. This PMD is implemented as thin wrapper of librte_vhost. It means librte_vhost is also needed to compile the PMD. The vhost messages will be handled only when a port is started. So start a port first, then invoke QEMU. The PMD has 2 parameters. - iface: The parameter is used to specify a path to connect to a virtio-net device. - queues: The parameter is used to specify the number of the queues virtio-net device has. (Default: 1) Here is an example. $ ./testpmd -c f -n 4 --vdev 'eth_vhost0,iface=/tmp/sock0,queues=1' -- -i To connect above testpmd, here is qemu command example. $ qemu-system-x86_64 \ -chardev socket,id=chr0,path=/tmp/sock0 \ -netdev vhost-user,id=net0,chardev=chr0,vhostforce,queues=1 \ -device virtio-net-pci,netdev=net0,mq=on Signed-off-by: Tetsuya Mukawa --- config/common_linuxapp | 6 + doc/guides/nics/index.rst | 1 + doc/guides/rel_notes/release_2_3.rst| 3 + drivers/net/Makefile| 4 + drivers/net/vhost/Makefile | 62 ++ drivers/net/vhost/rte_eth_vhost.c | 898 drivers/net/vhost/rte_eth_vhost.h | 109 drivers/net/vhost/rte_pmd_vhost_version.map | 11 + mk/rte.app.mk | 6 + 9 files changed, 1100 insertions(+) create mode 100644 drivers/net/vhost/Makefile create mode 100644 drivers/net/vhost/rte_eth_vhost.c create mode 100644 drivers/net/vhost/rte_eth_vhost.h create mode 100644 drivers/net/vhost/rte_pmd_vhost_version.map diff --git a/config/common_linuxapp b/config/common_linuxapp index 74bc515..357b557 100644 --- a/config/common_linuxapp +++ b/config/common_linuxapp @@ -514,6 +514,12 @@ CONFIG_RTE_LIBRTE_VHOST_NUMA=n CONFIG_RTE_LIBRTE_VHOST_DEBUG=n # +# Compile vhost PMD +# To compile, CONFIG_RTE_LIBRTE_VHOST should be enabled. +# +CONFIG_RTE_LIBRTE_PMD_VHOST=y + +# #Compile Xen domain0 support # CONFIG_RTE_LIBRTE_XEN_DOM0=n diff --git a/doc/guides/nics/index.rst b/doc/guides/nics/index.rst index 33c9cea..5819cdb 100644 --- a/doc/guides/nics/index.rst +++ b/doc/guides/nics/index.rst @@ -47,6 +47,7 @@ Network Interface Controller Drivers nfp szedata2 virtio +vhost vmxnet3 pcap_ring diff --git a/doc/guides/rel_notes/release_2_3.rst b/doc/guides/rel_notes/release_2_3.rst index 99de186..21a38c7 100644 --- a/doc/guides/rel_notes/release_2_3.rst +++ b/doc/guides/rel_notes/release_2_3.rst @@ -4,6 +4,9 @@ DPDK Release 2.3 New Features +* **Added vhost PMD.** + + Added virtual PMD that wraps librte_vhost. Resolved Issues --- diff --git a/drivers/net/Makefile b/drivers/net/Makefile index 6e4497e..4300b93 100644 --- a/drivers/net/Makefile +++ b/drivers/net/Makefile @@ -52,5 +52,9 @@ DIRS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio DIRS-$(CONFIG_RTE_LIBRTE_VMXNET3_PMD) += vmxnet3 DIRS-$(CONFIG_RTE_LIBRTE_PMD_XENVIRT) += xenvirt +ifeq ($(CONFIG_RTE_LIBRTE_VHOST),y) +DIRS-$(CONFIG_RTE_LIBRTE_PMD_VHOST) += vhost +endif # $(CONFIG_RTE_LIBRTE_VHOST) + include $(RTE_SDK)/mk/rte.sharelib.mk include $(RTE_SDK)/mk/rte.subdir.mk diff --git a/drivers/net/vhost/Makefile b/drivers/net/vhost/Makefile new file mode 100644 index 000..f49a69b --- /dev/null +++ b/drivers/net/vhost/Makefile @@ -0,0 +1,62 @@ +# BSD LICENSE +# +# Copyright (c) 2010-2016 Intel Corporation. +# All rights reserved. +# +# Redistribution and use in source and binary forms, with or without +# modification, are permitted provided that the following conditions +# are met: +# +# * Redistributions of source code must retain the above copyright +# notice, this list of conditions and the following disclaimer. +# * Redistributions in binary form must reproduce the above copyright +# notice, this list of conditions and the following disclaimer in +# the documentation and/or other materials provided with the +# distribution. +# * Neither the name of Intel corporation nor the names of its +# contributors may be used to endorse or promote products derived +# from this software without specific prior written permission. +# +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS +# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT +# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR +# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT +# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, +# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT +# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, +# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY +# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT +# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
[dpdk-dev] [PATCH v2 0/4] Various fixes for L2fwd-crypto
This patchset includes param handling, typo and statistics fixes in the L2fwd-crypto sample app. Changes in v2: - Include "Fixes" line Pablo de Lara (4): l2fwd-crypto: fix accumulated stats l2fwd-crypto: fix incorrect params in command line help l2fwd-crypto: fix auth params setting l2fwd-crypto: fix typos examples/l2fwd-crypto/main.c | 20 1 file changed, 12 insertions(+), 8 deletions(-) -- 2.5.0
[dpdk-dev] [PATCH v2 1/4] l2fwd-crypto: fix accumulated stats
Total number of packets (adding up packets RX/TX/dropped in all ports),
where being increased by the accumulated number of packets per port
every time the stats were printed, instead of the resetting
them.
Fixes: 387259bd6c67 ("examples/l2fwd-crypto: add sample application")
Signed-off-by: Pablo de Lara
---
examples/l2fwd-crypto/main.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/examples/l2fwd-crypto/main.c b/examples/l2fwd-crypto/main.c
index d70fc9a..928b285 100644
--- a/examples/l2fwd-crypto/main.c
+++ b/examples/l2fwd-crypto/main.c
@@ -205,17 +205,20 @@ struct l2fwd_crypto_statistics
crypto_statistics[RTE_MAX_ETHPORTS];
/* default period is 10 seconds */
static int64_t timer_period = 10 * TIMER_MILLISECOND * 1000;
-uint64_t total_packets_dropped = 0, total_packets_tx = 0, total_packets_rx = 0,
- total_packets_enqueued = 0, total_packets_dequeued = 0,
+uint64_t total_packets_enqueued = 0, total_packets_dequeued = 0,
total_packets_errors = 0;
/* Print out statistics on packets dropped */
static void
print_stats(void)
{
+ uint64_t total_packets_dropped, total_packets_tx, total_packets_rx;
unsigned portid;
uint64_t cdevid;
+ total_packets_dropped = 0;
+ total_packets_tx = 0;
+ total_packets_rx = 0;
const char clr[] = { 27, '[', '2', 'J', '\0' };
const char topLeft[] = { 27, '[', '1', ';', '1', 'H', '\0' };
--
2.5.0
[dpdk-dev] [PATCH v2 2/4] l2fwd-crypto: fix incorrect params in command line help
Fixes: 387259bd6c67 ("examples/l2fwd-crypto: add sample application")
Signed-off-by: Pablo de Lara
---
examples/l2fwd-crypto/main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/examples/l2fwd-crypto/main.c b/examples/l2fwd-crypto/main.c
index 928b285..37f59c4 100644
--- a/examples/l2fwd-crypto/main.c
+++ b/examples/l2fwd-crypto/main.c
@@ -669,8 +669,9 @@ l2fwd_crypto_usage(const char *prgname)
" --cipher_algo ALGO\n"
" --cipher_op ENCRYPT / DECRYPT\n"
" --cipher_key KEY\n"
+ " --iv IV\n"
- " --auth ALGO\n"
+ " --auth_algo ALGO\n"
" --auth_op GENERATE / VERIFY\n"
" --auth_key KEY\n"
--
2.5.0
[dpdk-dev] [PATCH v2 3/4] l2fwd-crypto: fix auth params setting
Fixes: 387259bd6c67 ("examples/l2fwd-crypto: add sample application")
Signed-off-by: Pablo de Lara
---
examples/l2fwd-crypto/main.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/examples/l2fwd-crypto/main.c b/examples/l2fwd-crypto/main.c
index 37f59c4..17a7774 100644
--- a/examples/l2fwd-crypto/main.c
+++ b/examples/l2fwd-crypto/main.c
@@ -791,7 +791,7 @@ parse_auth_op(enum rte_crypto_auth_operation *op, char
*optarg)
*op = RTE_CRYPTO_AUTH_OP_VERIFY;
return 0;
} else if (strcmp("GENERATE", optarg) == 0) {
- *op = RTE_CRYPTO_AUTH_OP_VERIFY;
+ *op = RTE_CRYPTO_AUTH_OP_GENERATE;
return 0;
}
@@ -829,11 +829,11 @@ l2fwd_crypto_parse_args_long_options(struct
l2fwd_crypto_options *options,
/* Authentication options */
else if (strcmp(lgopts[option_index].name, "auth_algo") == 0)
- return parse_auth_algo(&options->cipher_xform.auth.algo,
+ return parse_auth_algo(&options->auth_xform.auth.algo,
optarg);
else if (strcmp(lgopts[option_index].name, "auth_op") == 0)
- return parse_auth_op(&options->cipher_xform.auth.op,
+ return parse_auth_op(&options->auth_xform.auth.op,
optarg);
else if (strcmp(lgopts[option_index].name, "auth_key") == 0)
--
2.5.0
[dpdk-dev] [PATCH v2 4/4] l2fwd-crypto: fix typos
Fixes: 387259bd6c67 ("examples/l2fwd-crypto: add sample application")
Signed-off-by: Pablo de Lara
---
examples/l2fwd-crypto/main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/examples/l2fwd-crypto/main.c b/examples/l2fwd-crypto/main.c
index 17a7774..9145f1c 100644
--- a/examples/l2fwd-crypto/main.c
+++ b/examples/l2fwd-crypto/main.c
@@ -979,9 +979,9 @@ l2fwd_crypto_options_print(struct l2fwd_crypto_options
*options)
switch (options->cdev_type) {
case RTE_CRYPTODEV_AESNI_MB_PMD:
- printf("crytpodev type: AES-NI MB PMD\n"); break;
+ printf("cryptodev type: AES-NI MB PMD\n"); break;
case RTE_CRYPTODEV_QAT_PMD:
- printf("crytpodev type: QAT PMD\n"); break;
+ printf("cryptodev type: QAT PMD\n"); break;
default:
break;
}
--
2.5.0
[dpdk-dev] [PATCH 0/4] Various fixes for L2fwd-crypto
> -Original Message- > From: De Lara Guarch, Pablo > Sent: Wednesday, February 03, 2016 11:14 AM > To: Doherty, Declan > Cc: dev at dpdk.org; De Lara Guarch, Pablo > Subject: [PATCH 0/4] Various fixes for L2fwd-crypto > > This patchset includes param handling, typo and > statistics fixes in the L2fwd-crypto sample app. > > Pablo de Lara (4): > l2fwd-crypto: fix accumulated stats > l2fwd-crypto: fix incorrect params in command line help > l2fwd-crypto: fix auth params setting > l2fwd-crypto: fix typos > > examples/l2fwd-crypto/main.c | 20 > 1 file changed, 12 insertions(+), 8 deletions(-) > > -- > 2.5.0 Nack, forgot fixes line.
[dpdk-dev] [PATCH v3] testpmd: fix wrong prompt in tx_vlan set command handler
v3: * Reworded the patch subject and commit message, added detail for reproducing the bug. * Reordered the definitions of cmd_tx_vlan_set_portid and cmd_tx_vlan_set_vlanid to keep in consistency with cmd_tx_vlan_set.tokens. v2: * Removed the bug fix unrelated code change to make this patch a pure bug fix patch. * Fixed the "PATCH 1/2" mistake in the patch title, rewrote the subject. Wang Xiao W (1): testpmd: fix wrong prompt in tx_vlan set command handler app/test-pmd/cmdline.c | 18 +++--- app/test-pmd/config.c | 16 2 files changed, 19 insertions(+), 15 deletions(-) -- 1.9.3
[dpdk-dev] [PATCH v3] testpmd: fix wrong prompt in tx_vlan set command handler
When using testpmd, sometimes we forget the right order of port_id and
vid in "tx_vlan set (port_id) vlan_id[, vlan_id_outer]\n" command, and
input "tx_vlan set 51 0", we'll get a strange prompt saying "Error, as
QinQ has been enabled.".
In cmd_tx_vlan_set_parsed function, the first thing we do is checking
the port's vlan_offload capability, rather than checking validity of the
port_id, therefore if it's an invalid port_id we'll get the above wrong
message. We should always make sure that we get a valid port_id before
we do other things.
It's the similar issue for cmd_tx_vlan_set_qinq_parsed function.
Signed-off-by: Wang Xiao W
---
app/test-pmd/cmdline.c | 18 +++---
app/test-pmd/config.c | 16
2 files changed, 19 insertions(+), 15 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 6d28c1b..52179e6 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -2954,12 +2954,6 @@ cmd_tx_vlan_set_parsed(void *parsed_result,
__attribute__((unused)) void *data)
{
struct cmd_tx_vlan_set_result *res = parsed_result;
- int vlan_offload = rte_eth_dev_get_vlan_offload(res->port_id);
-
- if (vlan_offload & ETH_VLAN_EXTEND_OFFLOAD) {
- printf("Error, as QinQ has been enabled.\n");
- return;
- }
tx_vlan_set(res->port_id, res->vlan_id);
}
@@ -2970,12 +2964,12 @@ cmdline_parse_token_string_t cmd_tx_vlan_set_tx_vlan =
cmdline_parse_token_string_t cmd_tx_vlan_set_set =
TOKEN_STRING_INITIALIZER(struct cmd_tx_vlan_set_result,
set, "set");
-cmdline_parse_token_num_t cmd_tx_vlan_set_vlanid =
- TOKEN_NUM_INITIALIZER(struct cmd_tx_vlan_set_result,
- vlan_id, UINT16);
cmdline_parse_token_num_t cmd_tx_vlan_set_portid =
TOKEN_NUM_INITIALIZER(struct cmd_tx_vlan_set_result,
port_id, UINT8);
+cmdline_parse_token_num_t cmd_tx_vlan_set_vlanid =
+ TOKEN_NUM_INITIALIZER(struct cmd_tx_vlan_set_result,
+ vlan_id, UINT16);
cmdline_parse_inst_t cmd_tx_vlan_set = {
.f = cmd_tx_vlan_set_parsed,
@@ -3006,12 +3000,6 @@ cmd_tx_vlan_set_qinq_parsed(void *parsed_result,
__attribute__((unused)) void *data)
{
struct cmd_tx_vlan_set_qinq_result *res = parsed_result;
- int vlan_offload = rte_eth_dev_get_vlan_offload(res->port_id);
-
- if (!(vlan_offload & ETH_VLAN_EXTEND_OFFLOAD)) {
- printf("Error, as QinQ hasn't been enabled.\n");
- return;
- }
tx_qinq_set(res->port_id, res->vlan_id, res->vlan_id_outer);
}
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index 7088f6f..956d29c 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -1839,10 +1839,18 @@ vlan_tpid_set(portid_t port_id, uint16_t tp_id)
void
tx_vlan_set(portid_t port_id, uint16_t vlan_id)
{
+ int vlan_offload;
if (port_id_is_invalid(port_id, ENABLED_WARN))
return;
if (vlan_id_is_invalid(vlan_id))
return;
+
+ vlan_offload = rte_eth_dev_get_vlan_offload(port_id);
+ if (vlan_offload & ETH_VLAN_EXTEND_OFFLOAD) {
+ printf("Error, as QinQ has been enabled.\n");
+ return;
+ }
+
tx_vlan_reset(port_id);
ports[port_id].tx_ol_flags |= TESTPMD_TX_OFFLOAD_INSERT_VLAN;
ports[port_id].tx_vlan_id = vlan_id;
@@ -1851,12 +1859,20 @@ tx_vlan_set(portid_t port_id, uint16_t vlan_id)
void
tx_qinq_set(portid_t port_id, uint16_t vlan_id, uint16_t vlan_id_outer)
{
+ int vlan_offload;
if (port_id_is_invalid(port_id, ENABLED_WARN))
return;
if (vlan_id_is_invalid(vlan_id))
return;
if (vlan_id_is_invalid(vlan_id_outer))
return;
+
+ vlan_offload = rte_eth_dev_get_vlan_offload(port_id);
+ if (!(vlan_offload & ETH_VLAN_EXTEND_OFFLOAD)) {
+ printf("Error, as QinQ hasn't been enabled.\n");
+ return;
+ }
+
tx_vlan_reset(port_id);
ports[port_id].tx_ol_flags |= TESTPMD_TX_OFFLOAD_INSERT_QINQ;
ports[port_id].tx_vlan_id = vlan_id;
--
1.9.3
[dpdk-dev] [PATCH 1/2 v2] fm10k: Add Atwood Channel Support
Atwood Channel is intel 25G NIC, and this patch add the support in DPDK. Signed-off-by: Michael Qiu Acked-by: John McNamara --- drivers/net/fm10k/base/fm10k_osdep.h| 4 lib/librte_eal/common/include/rte_pci_dev_ids.h | 2 ++ 2 files changed, 6 insertions(+) diff --git a/drivers/net/fm10k/base/fm10k_osdep.h b/drivers/net/fm10k/base/fm10k_osdep.h index 6852ef0..9cb46ff 100644 --- a/drivers/net/fm10k/base/fm10k_osdep.h +++ b/drivers/net/fm10k/base/fm10k_osdep.h @@ -48,6 +48,10 @@ POSSIBILITY OF SUCH DAMAGE. #define BOULDER_RAPIDS_HW #endif +#ifndef ATWOOD_CHANNEL_HW +#define ATWOOD_CHANNEL_HW +#endif + #define STATIC static #define DEBUGFUNC(F)DEBUGOUT(F "\n"); #define DEBUGOUT(S, args...)PMD_DRV_LOG_RAW(DEBUG, S, ##args) diff --git a/lib/librte_eal/common/include/rte_pci_dev_ids.h b/lib/librte_eal/common/include/rte_pci_dev_ids.h index e31b934..cb0d177 100644 --- a/lib/librte_eal/common/include/rte_pci_dev_ids.h +++ b/lib/librte_eal/common/include/rte_pci_dev_ids.h @@ -530,9 +530,11 @@ RTE_PCI_DEV_ID_DECL_I40E(PCI_VENDOR_ID_INTEL, I40E_DEV_ID_10G_BASE_T_X722) #define FM10K_DEV_ID_PF 0x15A4 #define FM10K_DEV_ID_SDI_FM10420_QDA2 0x15D0 +#define FM10K_DEV_ID_SDI_FM10420_DA2 0x15D5 RTE_PCI_DEV_ID_DECL_FM10K(PCI_VENDOR_ID_INTEL, FM10K_DEV_ID_PF) RTE_PCI_DEV_ID_DECL_FM10K(PCI_VENDOR_ID_INTEL, FM10K_DEV_ID_SDI_FM10420_QDA2) +RTE_PCI_DEV_ID_DECL_FM10K(PCI_VENDOR_ID_INTEL, FM10K_DEV_ID_SDI_FM10420_DA2) /** Virtual IGB devices from e1000_hw.h **/ -- 1.9.3
[dpdk-dev] [PATCH 2/2 v2] fm10k: update doc for Atwood Channel
Atwood Channel is 25GbE NIC and belongs to Intel FM10K family, update the doc for it. Signed-off-by: Michael Qiu Acked-by: John McNamara --- Change log: 1. modify 20GbE to 25GbE doc/guides/rel_notes/release_2_3.rst | 2 ++ 1 file changed, 2 insertions(+) diff --git a/doc/guides/rel_notes/release_2_3.rst b/doc/guides/rel_notes/release_2_3.rst index 99de186..7dd9c0f 100644 --- a/doc/guides/rel_notes/release_2_3.rst +++ b/doc/guides/rel_notes/release_2_3.rst @@ -3,7 +3,9 @@ DPDK Release 2.3 New Features +* **New NIC Atwood Channel support.** + Added support for the Atwood Channel variant of Intel's fm10k NIC family. Resolved Issues --- -- 1.9.3
[dpdk-dev] [PATCH v2] i40e: fix vlan filtering
2016-02-04 00:41, Zhang, Helin: > From: Julien Meunier [mailto:julien.meunier at 6wind.com] > > INFO log level is used in order to keep code homogeneity: > > i40e_vsi_config_vlan_stripping or i40e_dev_init_vlan use this log level > > during > > failure for example. > > > > Tell me if ERR log level for VLAN filtering issue must be set. > There is a failure, and may result in uncertain behaviors which cannot be > ignored. > I'd suggest to use ERR but not INFO, though I am not so confident on that. > Could Thomas help give some guidance on that? Helin, about i40e internals, I follow your guidance :) If you consider it as a real error, yes we must log an error. About code homogeneity, Julien seems to have seen some errors in the driver which should be logged as such, right? It may be a separate effort to fix them. Thanks
[dpdk-dev] [PATCH 1/2 v2] fm10k: Add Atwood Channel Support
Hi, Best Regards, Mark > -Original Message- > From: Qiu, Michael > Sent: Thursday, February 04, 2016 4:36 PM > To: dev at dpdk.org > Cc: Chen, Jing D; Qiu, Michael > Subject: [PATCH 1/2 v2] fm10k: Add Atwood Channel Support > > Atwood Channel is intel 25G NIC, and this patch add the support > in DPDK. > > Signed-off-by: Michael Qiu > Acked-by: John McNamara Acked-by: Jing Chen
[dpdk-dev] [PATCH] i40e: fix the issue of port initialization failure
2016-02-04 00:50, Zhang, Helin: > From: Richardson, Bruce > > can you please add an appropriately "fixes" line to the patch, since the > > subject > > explicitly calls it out as a bug-fix. Also, the words "the issue" in the > > subject can > > be removed as they don't add value. It would also be worthwhile referencing > > the adminq in the subject too, since that is the failure being reported. How > > about: > > > > "i40e: fix adminq failure on port init" > > Oh, sorry, I forgot this patch. > Firmware finally fixed it in FVL5, and we need to use new AQ commands for > reading/writing some registers. > So I will drop this patch. Thanks! In such case, please mark it as "Rejected" in patchwork and self reply on the mailing list to advertise it is dropped. Thanks
[dpdk-dev] [PATCH 1/3] eal/x86: fix build with clang for old AVX
2016-02-04 03:35, Wang, Zhihong:
> > Subject: [PATCH 1/3] eal/x86: fix build with clang for old AVX
> >
> > When configuring RTE_MACHINE to "default", rte_memcpy implementation
> > is the default one (old AVX).
> > In this code, clang raises a warning thanks to -Wsometimes-uninitialized:
> >
> > rte_memcpy.h:838:6: error:
> > variable 'srcofs' is used uninitialized whenever 'if' condition is false
> > if (dstofss > 0) {
> > ^~~
> > rte_memcpy.h:849:6: note: uninitialized use occurs here
> > if (srcofs == 0) {
> > ^~
> >
> > It is fixed by initializing srcofs to 0.
> >
> > Fixes: 1ae817f9f887 ("eal/x86: tune memcpy for platforms without AVX512")
>
> Hi Thomas,
>
> Thanks for pointing this out!
> My last hasty modification on this is not correct.
>
> The patch below will fix it. All modifications are tested.
> Sorry for all the hassle! :'(
>
> "srcofs" should be calculated based on source address anyway.
OK
Please send a full patch as usual, thanks.
[dpdk-dev] [PATCH 2/2 v2] fm10k: update doc for Atwood Channel
Hi Michael, 2016-02-04 16:36, Michael Qiu: > Atwood Channel is 25GbE NIC and belongs to Intel FM10K family, > update the doc for it. > > Signed-off-by: Michael Qiu > Acked-by: John McNamara Next time, it would be better to send the doc changes and the related code changes in the same patch. Thanks
[dpdk-dev] [PATCH v6 0/4] add virtio offload support in us-vhost
Hi Thomas, Do you have comments on this patch set? The former version has actually got my ACK. If no objections, I will (or ask Jijiang to) make a rebase and fix the commit log and send another version out. --yliu On Mon, Dec 21, 2015 at 01:21:16PM +0800, Jijiang Liu wrote: > Adds virtio offload support in us-vhost. > > The patch set adds the feature negotiation of checksum and TSO between > us-vhost and vanilla Linux virtio guest, and add these offload features > support in the vhost lib, and change vhost sample to test them. > > In short, this patch set supports the followings, > > 1. DPDK vhost CSUM & TSO for VM2NIC case > > 2. CSUM and TSO support between legacy virtio-net and DPDK vhost for VM2VM > and NIC2VM cases. > > v6 change: > Rebase latest codes. > > v5 changes: > Add more clear descriptions to explain these changes. > reset the 'virtio_net_hdr' value in the virtio_enqueue_offload() function. > reorganize patches. > > > v4 change: > remove virtio-net change, only keep vhost changes. > add guest TX offload capabilities to support VM to VM case. > split the cleanup code as a separate patch. > > v3 change: > rebase latest codes. > > v2 change: > fill virtio device information for TX offloads. > > *** BLURB HERE *** > > Jijiang Liu (4): > add vhost offload capabilities > remove ipv4_hdr structure from vhost sample. > add guest offload setting ln the vhost lib. > change vhost application to test checksum and TSO for VM to NIC case > > examples/vhost/main.c | 120 - > lib/librte_vhost/vhost_rxtx.c | 150 > - > lib/librte_vhost/virtio-net.c |9 ++- > 3 files changed, 259 insertions(+), 20 deletions(-) > > -- > 1.7.7.6
[dpdk-dev] [PATCH v6 0/4] add virtio offload support in us-vhost
2016-02-04 17:08, Yuanhan Liu: > Hi Thomas, > > Do you have comments on this patch set? The former version has actually > got my ACK. If no objections, I will (or ask Jijiang to) make a rebase > and fix the commit log and send another version out. No comment, thanks
[dpdk-dev] [PATCH 1/3] eal/x86: fix build with clang for old AVX
2016-02-04 09:47, Thomas Monjalon:
> 2016-02-04 03:35, Wang, Zhihong:
> > > Subject: [PATCH 1/3] eal/x86: fix build with clang for old AVX
> > >
> > > When configuring RTE_MACHINE to "default", rte_memcpy implementation
> > > is the default one (old AVX).
> > > In this code, clang raises a warning thanks to -Wsometimes-uninitialized:
> > >
> > > rte_memcpy.h:838:6: error:
> > > variable 'srcofs' is used uninitialized whenever 'if' condition is false
> > > if (dstofss > 0) {
> > > ^~~
> > > rte_memcpy.h:849:6: note: uninitialized use occurs here
> > > if (srcofs == 0) {
> > > ^~
> > >
> > > It is fixed by initializing srcofs to 0.
> > >
> > > Fixes: 1ae817f9f887 ("eal/x86: tune memcpy for platforms without AVX512")
> >
> > Hi Thomas,
> >
> > Thanks for pointing this out!
> > My last hasty modification on this is not correct.
> >
> > The patch below will fix it. All modifications are tested.
> > Sorry for all the hassle! :'(
> >
> > "srcofs" should be calculated based on source address anyway.
>
> OK
> Please send a full patch as usual, thanks.
Sorry I've just caught you have already sent it. Thanks
[dpdk-dev] [PATCH v3 0/3] fm10k: enable FTAG based forwarding
Hi, Best Regards, Mark > -Original Message- > From: Wang, Xiao W > Sent: Thursday, February 04, 2016 11:39 AM > To: Chen, Jing D > Cc: dev at dpdk.org; Qiu, Michael; He, Shaopeng; Wang, Xiao W > Subject: [PATCH v3 0/3] fm10k: enable FTAG based forwarding > > v3: > * Removed "\n" in PMD_INIT_LOG. > > * Returned "-ENOTSUP" instead of -1 in VF FTAG use case. > > v2: > * Gave an error message for VF FTAG use case. > > * Added a notice in the doc to emphasize that application should ensure > an appropriate FTAG for every frame in FTAG based forwarding mode. > > Wang Xiao W (3): > fm10k: enable FTAG based forwarding > doc: add introduction for fm10k FTAG based forwarding > doc: update release note for fm10k FTAG support > > config/common_bsdapp | 1 + > config/common_linuxapp | 1 + > doc/guides/nics/fm10k.rst| 16 +++- > doc/guides/rel_notes/release_2_3.rst | 1 + > drivers/net/fm10k/fm10k_ethdev.c | 12 > drivers/net/fm10k/fm10k_rxtx.c | 17 + > drivers/net/fm10k/fm10k_rxtx_vec.c | 9 + > 7 files changed, 56 insertions(+), 1 deletion(-) > > -- > 1.9.3 Acked-by: Jing Chen
[dpdk-dev] [PATCH v3] testpmd: fix wrong prompt in tx_vlan set command handler
On Thu, Feb 04, 2016 at 04:27:32PM +0800, Wang Xiao W wrote: > When using testpmd, sometimes we forget the right order of port_id and > vid in "tx_vlan set (port_id) vlan_id[, vlan_id_outer]\n" command, and > input "tx_vlan set 51 0", we'll get a strange prompt saying "Error, as > QinQ has been enabled.". > > In cmd_tx_vlan_set_parsed function, the first thing we do is checking > the port's vlan_offload capability, rather than checking validity of the > port_id, therefore if it's an invalid port_id we'll get the above wrong > message. We should always make sure that we get a valid port_id before > we do other things. > > It's the similar issue for cmd_tx_vlan_set_qinq_parsed function. > > Signed-off-by: Wang Xiao W Please include a fixes line, in patches fixing problems. thanks, /Bruce
[dpdk-dev] PING: [PATCH v2] pmd/virtio: fix cannot start virtio dev after stop
Hello! Are there any news about this patch? We have got this problem for the
second time, it reproduces every time we try to use
ovs-dpdk inside virtual machine with virtio-net adapter.
Kind regards,
Pavel Fedin
Senior Engineer
Samsung Electronics Research center Russia
> -Original Message-
> From: Jianfeng Tan [mailto:jianfeng.tan at intel.com]
> Sent: Monday, January 11, 2016 9:16 AM
> To: dev at dpdk.org
> Cc: p.fedin at samsung.com; yuanhan.liu at linux.intel.com; Jianfeng Tan
> Subject: [PATCH v2] pmd/virtio: fix cannot start virtio dev after stop
>
> v2 changes:
> - Address compiling error.
> - Add Reported-by.
>
> Fix the issue that virtio device cannot be started after stopped.
>
> The field, hw->started, should be changed by virtio_dev_start/stop instead
> of virtio_dev_close.
>
> Reported-by: Pavel Fedin
> Signed-off-by: Jianfeng Tan
> Acked-by: Yuanhan Liu
>
> ---
> drivers/net/virtio/virtio_ethdev.c | 14 +-
> 1 file changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/virtio/virtio_ethdev.c
> b/drivers/net/virtio/virtio_ethdev.c
> index d928339..5bdd305 100644
> --- a/drivers/net/virtio/virtio_ethdev.c
> +++ b/drivers/net/virtio/virtio_ethdev.c
> @@ -490,11 +490,13 @@ virtio_dev_close(struct rte_eth_dev *dev)
>
> PMD_INIT_LOG(DEBUG, "virtio_dev_close");
>
> + if (hw->started == 1)
> + virtio_dev_stop(dev);
> +
> /* reset the NIC */
> if (pci_dev->driver->drv_flags & RTE_PCI_DRV_INTR_LSC)
> vtpci_irq_config(hw, VIRTIO_MSI_NO_VECTOR);
> vtpci_reset(hw);
> - hw->started = 0;
> virtio_dev_free_mbufs(dev);
> virtio_free_queues(dev);
> }
> @@ -1408,10 +1410,9 @@ eth_virtio_dev_uninit(struct rte_eth_dev *eth_dev)
> if (rte_eal_process_type() == RTE_PROC_SECONDARY)
> return -EPERM;
>
> - if (hw->started == 1) {
> - virtio_dev_stop(eth_dev);
> - virtio_dev_close(eth_dev);
> - }
> + /* Close it anyway since there's no way to know if closed */
> + virtio_dev_close(eth_dev);
> +
> pci_dev = eth_dev->pci_dev;
>
> eth_dev->dev_ops = NULL;
> @@ -1612,9 +1613,12 @@ static void
> virtio_dev_stop(struct rte_eth_dev *dev)
> {
> struct rte_eth_link link;
> + struct virtio_hw *hw = dev->data->dev_private;
>
> PMD_INIT_LOG(DEBUG, "stop");
>
> + hw->started = 0;
> +
> if (dev->data->dev_conf.intr_conf.lsc)
> rte_intr_disable(&dev->pci_dev->intr_handle);
>
> --
> 2.1.4
[dpdk-dev] [PATCH v3] i40e: fix vlan filtering
VLAN filtering was always performed, even if hw_vlan_filter was
disabled. During device initialization, default filter
RTE_MACVLAN_PERFECT_MATCH was applied. In this situation, all incoming
VLAN frames were dropped by the card (increase of the register RUPP - Rx
Unsupported Protocol).
In order to restore default behavior, if HW VLAN filtering is activated,
set a filter to match MAC and VLAN. If not, set a filter to only match
MAC.
Signed-off-by: Julien Meunier
---
Changes since v2:
- switch log level from INFO to ERR in case of failure
Changes since v1:
- use ether_addr_copy() for mac copy
- add more debug messages in case of failure
- update all existing filters when multiple mac addresses have been configured
- when adding new mac address, use correct filter
TODO:
- i40e_update_default_filter_setting always forces to
RTE_MACVLAN_PERFECT_MATCH.
=> The type of filter should be changed according to vlan filter setting.
- What happens if vlan filter setting changes when various filters are already
set like RTE_MACVLAN_PERFECT_MATCH, RTE_MACVLAN_PERFECT_MATCH,
RTE_MAC_HASH_MATCH, RTE_MACVLAN_HASH_MATCH ?
=> With testpmd, it is possible to add manually these filters. But when
changing vlan filter setting, all previous filter set manually are overriden.
---
drivers/net/i40e/i40e_ethdev.c | 73 --
drivers/net/i40e/i40e_ethdev.h | 1 +
2 files changed, 72 insertions(+), 2 deletions(-)
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index bf6220d..750206b 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -2332,6 +2332,13 @@ i40e_vlan_offload_set(struct rte_eth_dev *dev, int mask)
struct i40e_pf *pf = I40E_DEV_PRIVATE_TO_PF(dev->data->dev_private);
struct i40e_vsi *vsi = pf->main_vsi;
+ if (mask & ETH_VLAN_FILTER_MASK) {
+ if (dev->data->dev_conf.rxmode.hw_vlan_filter)
+ i40e_vsi_config_vlan_filter(vsi, TRUE);
+ else
+ i40e_vsi_config_vlan_filter(vsi, FALSE);
+ }
+
if (mask & ETH_VLAN_STRIP_MASK) {
/* Enable or disable VLAN stripping */
if (dev->data->dev_conf.rxmode.hw_vlan_strip)
@@ -2583,7 +2590,10 @@ i40e_macaddr_add(struct rte_eth_dev *dev,
}
(void)rte_memcpy(&mac_filter.mac_addr, mac_addr, ETHER_ADDR_LEN);
- mac_filter.filter_type = RTE_MACVLAN_PERFECT_MATCH;
+ if (dev->data->dev_conf.rxmode.hw_vlan_filter)
+ mac_filter.filter_type = RTE_MACVLAN_PERFECT_MATCH;
+ else
+ mac_filter.filter_type = RTE_MAC_PERFECT_MATCH;
if (pool == 0)
vsi = pf->main_vsi;
@@ -4156,6 +4166,63 @@ fail_mem:
return NULL;
}
+/* Configure vlan filter on or off */
+int
+i40e_vsi_config_vlan_filter(struct i40e_vsi *vsi, bool on)
+{
+ int i, num;
+ struct i40e_mac_filter *f;
+ struct i40e_mac_filter_info *mac_filter;
+ enum rte_mac_filter_type desired_filter;
+ int ret = I40E_SUCCESS;
+
+ if (on) {
+ /* Filter to match MAC and VLAN */
+ desired_filter = RTE_MACVLAN_PERFECT_MATCH;
+ } else {
+ /* Filter to match only MAC */
+ desired_filter = RTE_MAC_PERFECT_MATCH;
+ }
+
+ num = vsi->mac_num;
+
+ mac_filter = rte_zmalloc("mac_filter_info_data",
+num * sizeof(*mac_filter), 0);
+ if (mac_filter == NULL) {
+ PMD_DRV_LOG(ERR, "failed to allocate memory");
+ return I40E_ERR_NO_MEMORY;
+ }
+
+ i = 0;
+
+ /* Remove all existing mac */
+ TAILQ_FOREACH(f, &vsi->mac_list, next) {
+ mac_filter[i] = f->mac_info;
+ ret = i40e_vsi_delete_mac(vsi, &f->mac_info.mac_addr);
+ if (ret) {
+ PMD_DRV_LOG(ERR, "Update VSI failed to %s vlan filter",
+ on ? "enable" : "disable");
+ goto DONE;
+ }
+ i++;
+ }
+
+ /* Override with new filter */
+ for (i = 0; i < num; i++) {
+ mac_filter[i].filter_type = desired_filter;
+ ret = i40e_vsi_add_mac(vsi, &mac_filter[i]);
+ if (ret) {
+ PMD_DRV_LOG(ERR, "Update VSI failed to %s vlan filter",
+ on ? "enable" : "disable");
+ goto DONE;
+ }
+ }
+
+DONE:
+ rte_free(mac_filter);
+ return ret;
+}
+
/* Configure vlan stripping on or off */
int
i40e_vsi_config_vlan_stripping(struct i40e_vsi *vsi, bool on)
@@ -4203,9 +4270,11 @@ i40e_dev_init_vlan(struct rte_eth_dev *dev)
{
struct rte_eth_dev_data *data = dev->data;
int ret;
+ int mask = 0;
/* Apply vlan offload setting */
- i40e_vlan_offload_set(dev, ETH_VLAN_STRIP_MASK);
[dpdk-dev] [PATCH v7 2/2] vhost: Add VHOST PMD
On Thu, Feb 04, 2016 at 04:26:31PM +0900, Tetsuya Mukawa wrote:
Hi Tetsuya,
> The patch introduces a new PMD. This PMD is implemented as thin wrapper
> of librte_vhost. It means librte_vhost is also needed to compile the PMD.
> The vhost messages will be handled only when a port is started. So start
> a port first, then invoke QEMU.
>
> The PMD has 2 parameters.
> - iface: The parameter is used to specify a path to connect to a
>virtio-net device.
> - queues: The parameter is used to specify the number of the queues
>virtio-net device has.
>(Default: 1)
>
> Here is an example.
> $ ./testpmd -c f -n 4 --vdev 'eth_vhost0,iface=/tmp/sock0,queues=1' -- -i
>
> To connect above testpmd, here is qemu command example.
>
> $ qemu-system-x86_64 \
>
> -chardev socket,id=chr0,path=/tmp/sock0 \
> -netdev vhost-user,id=net0,chardev=chr0,vhostforce,queues=1 \
> -device virtio-net-pci,netdev=net0,mq=on
>
> Signed-off-by: Tetsuya Mukawa
Please find some more comments, mostly minor nits,
please feel free to add my ack for next version of this patch:
Acked-by: Ferruh Yigit
<...>
> diff --git a/drivers/net/vhost/rte_eth_vhost.c
> b/drivers/net/vhost/rte_eth_vhost.c
> new file mode 100644
> index 000..b2305c2
> --- /dev/null
> +++ b/drivers/net/vhost/rte_eth_vhost.c
<...>
> +
> +struct pmd_internal {
> + TAILQ_ENTRY(pmd_internal) next;
> + char *dev_name;
> + char *iface_name;
> + uint8_t port_id;
You can also get rid of port_id too, if you keep list of rte_eth_dev.
But this is not so important, keep as it is if you want to.
> +
> + volatile uint16_t once;
> +};
> +
<...>
> +
> +static int
> +new_device(struct virtio_net *dev)
> +{
<...>
> +
> + for (i = 0; i < eth_dev->data->nb_rx_queues; i++) {
> + vq = eth_dev->data->rx_queues[i];
> + if (vq == NULL)
can vq be NULL? It is allocated in rx/tx_queue_setup() and there is already a
NULL check there?
> + continue;
> + vq->device = dev;
> + vq->internal = internal;
> + rte_vhost_enable_guest_notification(dev, vq->virtqueue_id, 0);
> + }
> + for (i = 0; i < eth_dev->data->nb_tx_queues; i++) {
> + vq = eth_dev->data->tx_queues[i];
> + if (vq == NULL)
> + continue;
> + vq->device = dev;
> + vq->internal = internal;
> + rte_vhost_enable_guest_notification(dev, vq->virtqueue_id, 0);
> + }
> +
> + dev->flags |= VIRTIO_DEV_RUNNING;
> + dev->priv = eth_dev;
> + eth_dev->data->dev_link.link_status = 1;
> +
> + for (i = 0; i < eth_dev->data->nb_rx_queues; i++) {
> + vq = eth_dev->data->rx_queues[i];
> + if (vq == NULL)
> + continue;
> + rte_atomic32_set(&vq->allow_queuing, 1);
> + }
> + for (i = 0; i < eth_dev->data->nb_tx_queues; i++) {
> + vq = eth_dev->data->tx_queues[i];
> + if (vq == NULL)
> + continue;
> + rte_atomic32_set(&vq->allow_queuing, 1);
> + }
> +
> + RTE_LOG(INFO, PMD, "New connection established\n");
> +
> + _rte_eth_dev_callback_process(eth_dev, RTE_ETH_EVENT_INTR_LSC);
> +
> + return 0;
> +}
> +
<...>
> +
> +static int
> +vring_state_changed(struct virtio_net *dev, uint16_t vring, int enable)
> +{
> + struct rte_vhost_vring_state *state;
> + struct pmd_internal *internal;
> +#ifdef RTE_LIBRTE_VHOST_NUMA
> + int newnode, ret;
> +#endif
> +
> + if (dev == NULL) {
> + RTE_LOG(ERR, PMD, "Invalid argument\n");
> + return -1;
> + }
> +
> + internal = find_internal_resource(dev->ifname);
> + if (internal == NULL) {
> + RTE_LOG(ERR, PMD, "Invalid interface name: %s\n", dev->ifname);
> + return -1;
> + }
> +
> + state = vring_states[internal->port_id];
> + if (!state) {
> + RTE_LOG(ERR, PMD, "Unused port id: %d\n", internal->port_id);
> + return -1;
> + }
> +
> +#ifdef RTE_LIBRTE_VHOST_NUMA
> + ret = get_mempolicy(&newnode, NULL, 0, dev,
> + MPOL_F_NODE | MPOL_F_ADDR);
> + if (ret < 0) {
> + RTE_LOG(ERR, PMD, "Unknow numa node\n");
> + return -1;
> + }
> +
> + rte_eth_devices[internal->port_id].data->numa_node = newnode;
If you prefer to keep the list of device instead of list of internal data, can
escape accessing global device array
> +#endif
> + rte_spinlock_lock(&state->lock);
> + state->cur[vring] = enable;
> + state->max_vring = RTE_MAX(vring, state->max_vring);
> + rte_spinlock_unlock(&state->lock);
> +
> + RTE_LOG(INFO, PMD, "vring%u is %s\n",
> + vring, enable ? "enabled" : "disabled");
> +
> + _rte_eth_dev_callback_process(&rte_eth_devices[internal->port_id],
> + RTE_ETH_EVENT_QUEUE_STATE_CHANGE)
[dpdk-dev] [PATCH v2] fm10k: enable PCIe port level Loopback Suppression
In FM10K, a single PCIe port can derive out a few logical ports,
like SRIOV PF/VF devices, VMDQ objects. To better manage them, FM10K
silicon assigned a Unique GLORT ID to each logical ports.
When a logical port sends a broadcast packet, the silicon will flood
it to all Logical ports, including the one sent the broadcast packet.
To prevent this, silicon has a rxq register to fill the glort id of
the logical port that queue binds to.
FM10K has a switch core inside, which has another loopback suppression
mechanism in the switch level. Switch level loopback suppression mostly
works for the ether port traffic.
This patch assigns a SGLORT for each RX queue, and enables PCIe port
level Loopback Suppression.
Signed-off-by: Shaopeng He
---
drivers/net/fm10k/fm10k_ethdev.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_ethdev.c
index f6eb05d..60f821a 100644
--- a/drivers/net/fm10k/fm10k_ethdev.c
+++ b/drivers/net/fm10k/fm10k_ethdev.c
@@ -690,12 +690,15 @@ static int
fm10k_dev_rx_init(struct rte_eth_dev *dev)
{
struct fm10k_hw *hw = FM10K_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+ struct fm10k_macvlan_filter_info *macvlan;
int i, ret;
struct fm10k_rx_queue *rxq;
uint64_t base_addr;
uint32_t size;
uint32_t rxdctl = FM10K_RXDCTL_WRITE_BACK_MIN_DELAY;
+ uint32_t logic_port = hw->mac.dglort_map;
uint16_t buf_size;
+ uint16_t queue_stride = 0;
/* Disable RXINT to avoid possible interrupt */
for (i = 0; i < hw->mac.max_queues; i++)
@@ -735,7 +738,8 @@ fm10k_dev_rx_init(struct rte_eth_dev *dev)
buf_size -= FM10K_RX_DATABUF_ALIGN;
FM10K_WRITE_REG(hw, FM10K_SRRCTL(i),
- buf_size >> FM10K_SRRCTL_BSIZEPKT_SHIFT);
+ (buf_size >> FM10K_SRRCTL_BSIZEPKT_SHIFT) |
+ FM10K_SRRCTL_LOOPBACK_SUPPRESS);
/* It adds dual VLAN length for supporting dual VLAN */
if ((dev->data->dev_conf.rxmode.max_rx_pkt_len +
@@ -762,6 +766,18 @@ fm10k_dev_rx_init(struct rte_eth_dev *dev)
/* Decide the best RX function */
fm10k_set_rx_function(dev);
+ /* update RX_SGLORT for loopback suppress*/
+ if (hw->mac.type != fm10k_mac_pf)
+ return 0;
+ macvlan = FM10K_DEV_PRIVATE_TO_MACVLAN(dev->data->dev_private);
+ if (macvlan->nb_queue_pools)
+ queue_stride = dev->data->nb_rx_queues /
macvlan->nb_queue_pools;
+ for (i = 0; i < dev->data->nb_rx_queues; ++i) {
+ if (i && queue_stride && !(i % queue_stride))
+ logic_port++;
+ FM10K_WRITE_REG(hw, FM10K_RX_SGLORT(i), logic_port);
+ }
+
return 0;
}
--
1.9.3
[dpdk-dev] [PATCH v2] fm10k: fix switch manager high CPU usage
fm10k switch core uses source MAC + VID + SGLORT to do look up in MAC table. If no match, an exception interrupt will be sent to the switch manager. Too much of this kind of exception interrupts cause switch manager side high CPU usage. To reproduce this issue, one DPDK testpmd runs on a server with one fm10k NIC, mac forwards test traffic from one of fm10k ports to another port. The CPU usage for the switch manager will go up to about 20% for test traffic rate at 10G bps, comparing to near 0% for no test traffic. This patch fixes this issue. A default SGLORT is assigned to each TX queue. This default value works for non-VMDq mode and current VMDq example. For advanced VMDq usage, e.g. different source MAC address for different TX queue, FTAG forwarding function could be used to change this default SGLORT value. Signed-off-by: Shaopeng He --- drivers/net/fm10k/fm10k_ethdev.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_ethdev.c index e4aed94..f6eb05d 100644 --- a/drivers/net/fm10k/fm10k_ethdev.c +++ b/drivers/net/fm10k/fm10k_ethdev.c @@ -675,6 +675,9 @@ fm10k_dev_tx_init(struct rte_eth_dev *dev) FM10K_WRITE_REG(hw, FM10K_TDBAH(i), base_addr >> (CHAR_BIT * sizeof(uint32_t))); FM10K_WRITE_REG(hw, FM10K_TDLEN(i), size); + + /* assign default SGLORT for each TX queue */ + FM10K_WRITE_REG(hw, FM10K_TX_SGLORT(i), hw->mac.dglort_map); } /* set up vector or scalar TX function as appropriate */ -- 1.9.3
[dpdk-dev] [PATCH 1/5] mempool: add external mempool manager support
On Wed, Feb 03, 2016 at 02:16:06PM +, Hunt, David wrote:
> On 28/01/2016 17:52, Jerin Jacob wrote:
> >On Tue, Jan 26, 2016 at 05:25:51PM +, David Hunt wrote:
> >>Adds the new rte_mempool_create_ext api and callback mechanism for
> >>external mempool handlers
> >>
> >>Modifies the existing rte_mempool_create to set up the handler_idx to
> >>the relevant mempool handler based on the handler name:
> >>ring_sp_sc
> >>ring_mp_mc
> >>ring_sp_mc
> >>ring_mp_sc
> >>
> >>Signed-off-by: David Hunt
> >>---
[snip]
> >>+ if (flags & MEMPOOL_F_USE_STACK)
> >>+ mp->handler_idx = rte_get_mempool_handler("stack");
> >>+ else if (flags & (MEMPOOL_F_SP_PUT | MEMPOOL_F_SC_GET))
> >>+ mp->handler_idx = rte_get_mempool_handler("ring_sp_sc");
> >>+ else if (flags & MEMPOOL_F_SP_PUT)
> >>+ mp->handler_idx = rte_get_mempool_handler("ring_sp_mc");
> >>+ else if (flags & MEMPOOL_F_SC_GET)
> >>+ mp->handler_idx = rte_get_mempool_handler("ring_mp_sc");
> >>+ else
> >>+ mp->handler_idx = rte_get_mempool_handler("ring_mp_mc");
> >>+
> >
> >Why still use flag based selection? Why not "name" based? See below
> >for more description
>
>
> The old API does not have a 'name' parameter, so needs to work out which
> handler to use based on the flags. This is not necessary in the new API
> call, and so it uses the "name" based index.
>
I agree. But the old API to new API mapping still can be done like
below,
rte_mempool_create -> rte_mempool_create_ext(..,"ring_mp_mc")
[snip]
>
> >>+ /* init the mempool structure */
> >>+ mp = mz->addr;
> >>+ memset(mp, 0, sizeof(*mp));
> >>+ snprintf(mp->name, sizeof(mp->name), "%s", name);
> >>+ mp->phys_addr = mz->phys_addr;
> >>+ mp->size = n;
> >>+ mp->flags = flags;
> >>+ mp->cache_size = cache_size;
> >>+ mp->cache_flushthresh = CALC_CACHE_FLUSHTHRESH(cache_size);
> >>+ mp->private_data_size = private_data_size;
> >>+ mp->handler_idx = handler_idx;
> >>+ mp->elt_size = elt_size;
> >>+ mp->rt_pool = rte_mempool_ext_alloc(mp, name, n, socket_id, flags);
> >
> >
> >IMO, We can avoid the duplicaition of above code with rte_mempool_create.
> >i.e rte_mempool_create -> rte_mempool_create_ext(..,"ring_mp_mc")
>
>
> rte_mempool_create is not really a subset of rte_mempool_create_ext, so
> doing this would not be possible. I did have a look at this before pusing
> the patch, but the code was so different in each case I decided to leave
> them as is. Maybe break out the section that sets up the mempool structure
> in to a separate functinon?
Yes, Their are a lot of common code between
rte_mempool_create/rte_mempool_xmem_create and rte_mempool_create_ext.
IMO, we need to converge these functions. Otherwise, a new feature in
mempool would call for changing in both places and it's difficult to
maintain.
In my view, both external and internal pool manager should have the same
code for creation and just the backend put/get/alloc function
pointers will be different to maintain the functional consistency.
Thanks, comments appreciated.
Jerin
[dpdk-dev] [RFC 0/3] Use common Linux tools to control DPDK ports
On Tue, Jan 19, 2016 at 01:29:32PM +0200, Panu Matilainen wrote: > On 01/19/2016 11:59 AM, Ferruh Yigit wrote: >> On Mon, Jan 18, 2016 at 11:20:02AM -0500, Aaron Conole wrote: >>> Ferruh Yigit writes: This work is to make DPDK ports more visible and to enable using common Linux tools to configure DPDK ports. >>> >>> This is a good goal. Only question - why use an additional kernel module >>> to do this? Is it _JUST_ for ethtool support? >> >> Kernel module used to create/destroy Linux net_devices, and module has a >> simple >> driver for that device which only handles control messages by passing them >> into >> userspace. >> >> To represent DPDK ports as Linux net_devices we need kernel support. >> >>> I think the other stuff >>> can be accomplished using netlink sockets + messages, no? >> >> Netlink sockets just used to communicate kernel-space - user-space, this is >> not >> why we need a kernel module, for example this communication is implemented in >> original KNI as part of FIFO. >> >>> The only >>> trepidation I would have with something like this is the support from >>> major vendors - out of tree modules are not generally supportable. Might >>> be good to get some of the ethtool commands as netlink messages as well, >>> then it is supportable with no 3rd party kernel modules. >> >> Yes, there is a out of three module problem for some distros, but >> unfortunately >> we are not able to find a solution for this case without an external kernel >> module. >> >> This patch is still an RFC and if we receive suggested solution without a >> kernel >> module, we can work on it together. > > If it has to be in the kernel then you need to find a design that is > upstreamable. Out of tree kernel modules are not a solution, they're a > problem that people are working on eliminating. > Hi Stephen, and other Linux experts in the mail list, Can you please help finding a upstreamable solution for kernel control path? Mainly what we are looking for is userspace network driver support in kernel, similar to what FUSE does but a much simple version. Above KCP module basically does this, by having a network driver which passing requests to userspace network driver, but it is not generic enough. I wonder if it is possible make it more generic by extending rtnetlink support: 1- Add a new network driver to Linux (or update existing one like tun) to forward requests, get responses. 2- Extend rtnelink to support to attach any userspace driver to this device? (ip link set uspace ?) Does this make sense? rtnetlink already supports creating interfaces, and it provides kernel/user space communication, with "attach" support interface learns about it's peer in usersppace and can communicate. FUSE like communication method also can be alternative to transfer request and responses, but since rtnelink support exists, no need to create something new think. Thanks, ferruh
[dpdk-dev] PING: [PATCH v2] pmd/virtio: fix cannot start virtio dev after stop
CC Thomas.
--yliu
On Thu, Feb 04, 2016 at 01:29:19PM +0300, Pavel Fedin wrote:
> Hello! Are there any news about this patch? We have got this problem for the
> second time, it reproduces every time we try to use
> ovs-dpdk inside virtual machine with virtio-net adapter.
>
> Kind regards,
> Pavel Fedin
> Senior Engineer
> Samsung Electronics Research center Russia
>
>
> > -Original Message-
> > From: Jianfeng Tan [mailto:jianfeng.tan at intel.com]
> > Sent: Monday, January 11, 2016 9:16 AM
> > To: dev at dpdk.org
> > Cc: p.fedin at samsung.com; yuanhan.liu at linux.intel.com; Jianfeng Tan
> > Subject: [PATCH v2] pmd/virtio: fix cannot start virtio dev after stop
> >
> > v2 changes:
> > - Address compiling error.
> > - Add Reported-by.
> >
> > Fix the issue that virtio device cannot be started after stopped.
> >
> > The field, hw->started, should be changed by virtio_dev_start/stop instead
> > of virtio_dev_close.
> >
> > Reported-by: Pavel Fedin
> > Signed-off-by: Jianfeng Tan
> > Acked-by: Yuanhan Liu
> >
> > ---
> > drivers/net/virtio/virtio_ethdev.c | 14 +-
> > 1 file changed, 9 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/net/virtio/virtio_ethdev.c
> > b/drivers/net/virtio/virtio_ethdev.c
> > index d928339..5bdd305 100644
> > --- a/drivers/net/virtio/virtio_ethdev.c
> > +++ b/drivers/net/virtio/virtio_ethdev.c
> > @@ -490,11 +490,13 @@ virtio_dev_close(struct rte_eth_dev *dev)
> >
> > PMD_INIT_LOG(DEBUG, "virtio_dev_close");
> >
> > + if (hw->started == 1)
> > + virtio_dev_stop(dev);
> > +
> > /* reset the NIC */
> > if (pci_dev->driver->drv_flags & RTE_PCI_DRV_INTR_LSC)
> > vtpci_irq_config(hw, VIRTIO_MSI_NO_VECTOR);
> > vtpci_reset(hw);
> > - hw->started = 0;
> > virtio_dev_free_mbufs(dev);
> > virtio_free_queues(dev);
> > }
> > @@ -1408,10 +1410,9 @@ eth_virtio_dev_uninit(struct rte_eth_dev *eth_dev)
> > if (rte_eal_process_type() == RTE_PROC_SECONDARY)
> > return -EPERM;
> >
> > - if (hw->started == 1) {
> > - virtio_dev_stop(eth_dev);
> > - virtio_dev_close(eth_dev);
> > - }
> > + /* Close it anyway since there's no way to know if closed */
> > + virtio_dev_close(eth_dev);
> > +
> > pci_dev = eth_dev->pci_dev;
> >
> > eth_dev->dev_ops = NULL;
> > @@ -1612,9 +1613,12 @@ static void
> > virtio_dev_stop(struct rte_eth_dev *dev)
> > {
> > struct rte_eth_link link;
> > + struct virtio_hw *hw = dev->data->dev_private;
> >
> > PMD_INIT_LOG(DEBUG, "stop");
> >
> > + hw->started = 0;
> > +
> > if (dev->data->dev_conf.intr_conf.lsc)
> > rte_intr_disable(&dev->pci_dev->intr_handle);
> >
> > --
> > 2.1.4
>
[dpdk-dev] [RFC 0/3] Use common Linux tools to control DPDK ports
On Thu, Feb 04, 2016 at 01:30:35PM +, Ferruh Yigit wrote: > On Tue, Jan 19, 2016 at 01:29:32PM +0200, Panu Matilainen wrote: > > On 01/19/2016 11:59 AM, Ferruh Yigit wrote: > >> On Mon, Jan 18, 2016 at 11:20:02AM -0500, Aaron Conole wrote: > >>> Ferruh Yigit writes: > This work is to make DPDK ports more visible and to enable using common > Linux tools to configure DPDK ports. > >>> > >>> This is a good goal. Only question - why use an additional kernel module > >>> to do this? Is it _JUST_ for ethtool support? > >> > >> Kernel module used to create/destroy Linux net_devices, and module has a > >> simple > >> driver for that device which only handles control messages by passing them > >> into > >> userspace. > >> > >> To represent DPDK ports as Linux net_devices we need kernel support. > >> > >>> I think the other stuff > >>> can be accomplished using netlink sockets + messages, no? > >> > >> Netlink sockets just used to communicate kernel-space - user-space, this > >> is not > >> why we need a kernel module, for example this communication is implemented > >> in > >> original KNI as part of FIFO. > >> > >>> The only > >>> trepidation I would have with something like this is the support from > >>> major vendors - out of tree modules are not generally supportable. Might > >>> be good to get some of the ethtool commands as netlink messages as well, > >>> then it is supportable with no 3rd party kernel modules. > >> > >> Yes, there is a out of three module problem for some distros, but > >> unfortunately > >> we are not able to find a solution for this case without an external > >> kernel module. > >> > >> This patch is still an RFC and if we receive suggested solution without a > >> kernel > >> module, we can work on it together. > > > > If it has to be in the kernel then you need to find a design that is > > upstreamable. Out of tree kernel modules are not a solution, they're a > > problem that people are working on eliminating. > > > > Hi Stephen, and other Linux experts in the mail list, forget to add Stephen Hemminger to cc, doing now. > > Can you please help finding a upstreamable solution for kernel control path? > > Mainly what we are looking for is userspace network driver support in kernel, > similar to what FUSE does but a much simple version. > > Above KCP module basically does this, by having a network driver which > passing requests to userspace network driver, but it is not generic enough. > > I wonder if it is possible make it more generic by extending rtnetlink > support: > 1- Add a new network driver to Linux (or update existing one like tun) to > forward requests, get responses. > 2- Extend rtnelink to support to attach any userspace driver to this device? > (ip link set uspace ?) > > Does this make sense? > > rtnetlink already supports creating interfaces, and it provides kernel/user > space communication, > with "attach" support interface learns about it's peer in usersppace and can > communicate. > > FUSE like communication method also can be alternative to transfer request > and responses, but since rtnelink support exists, no need to create something > new think. > > Thanks, > ferruh >
[dpdk-dev] [PATCH 1/2 v2] fm10k: Add Atwood Channel Support
Tested-by: Marvin Liu > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Michael Qiu > Sent: Thursday, February 04, 2016 4:36 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH 1/2 v2] fm10k: Add Atwood Channel Support > > Atwood Channel is intel 25G NIC, and this patch add the support > in DPDK. > > Signed-off-by: Michael Qiu > Acked-by: John McNamara > --- > drivers/net/fm10k/base/fm10k_osdep.h| 4 > lib/librte_eal/common/include/rte_pci_dev_ids.h | 2 ++ > 2 files changed, 6 insertions(+) > > diff --git a/drivers/net/fm10k/base/fm10k_osdep.h > b/drivers/net/fm10k/base/fm10k_osdep.h > index 6852ef0..9cb46ff 100644 > --- a/drivers/net/fm10k/base/fm10k_osdep.h > +++ b/drivers/net/fm10k/base/fm10k_osdep.h > @@ -48,6 +48,10 @@ POSSIBILITY OF SUCH DAMAGE. > #define BOULDER_RAPIDS_HW > #endif > > +#ifndef ATWOOD_CHANNEL_HW > +#define ATWOOD_CHANNEL_HW > +#endif > + > #define STATIC static > #define DEBUGFUNC(F)DEBUGOUT(F "\n"); > #define DEBUGOUT(S, args...)PMD_DRV_LOG_RAW(DEBUG, S, ##args) > diff --git a/lib/librte_eal/common/include/rte_pci_dev_ids.h > b/lib/librte_eal/common/include/rte_pci_dev_ids.h > index e31b934..cb0d177 100644 > --- a/lib/librte_eal/common/include/rte_pci_dev_ids.h > +++ b/lib/librte_eal/common/include/rte_pci_dev_ids.h > @@ -530,9 +530,11 @@ RTE_PCI_DEV_ID_DECL_I40E(PCI_VENDOR_ID_INTEL, > I40E_DEV_ID_10G_BASE_T_X722) > > #define FM10K_DEV_ID_PF 0x15A4 > #define FM10K_DEV_ID_SDI_FM10420_QDA2 0x15D0 > +#define FM10K_DEV_ID_SDI_FM10420_DA2 0x15D5 > > RTE_PCI_DEV_ID_DECL_FM10K(PCI_VENDOR_ID_INTEL, FM10K_DEV_ID_PF) > RTE_PCI_DEV_ID_DECL_FM10K(PCI_VENDOR_ID_INTEL, > FM10K_DEV_ID_SDI_FM10420_QDA2) > +RTE_PCI_DEV_ID_DECL_FM10K(PCI_VENDOR_ID_INTEL, > FM10K_DEV_ID_SDI_FM10420_DA2) > > /** Virtual IGB devices from e1000_hw.h > **/ > > -- > 1.9.3
[dpdk-dev] [RFC 0/3] Use common Linux tools to control DPDK ports
Hi Ferruh, I missed your original reply to me. Sorry. Ferruh Yigit writes: > On Tue, Jan 19, 2016 at 01:29:32PM +0200, Panu Matilainen wrote: >> On 01/19/2016 11:59 AM, Ferruh Yigit wrote: >>> On Mon, Jan 18, 2016 at 11:20:02AM -0500, Aaron Conole wrote: Ferruh Yigit writes: > This work is to make DPDK ports more visible and to enable using common > Linux tools to configure DPDK ports. This is a good goal. Only question - why use an additional kernel module to do this? Is it _JUST_ for ethtool support? >>> >>> Kernel module used to create/destroy Linux net_devices, and module has a >>> simple >>> driver for that device which only handles control messages by passing them >>> into >>> userspace. >>> >>> To represent DPDK ports as Linux net_devices we need kernel support. Why? Just create tun/tap interface, no? Then you get a queue into the network stack, as well. Subscribe to netlink, and you can get all of the changes that happen in the system - just look for those messages that relate to your tun device. At least, that's what I see right away (and I have some private patches for this, and you can take them over if you want). I think most of the stuff you are trying to solve already exists, but I am probably misunderstanding something (apologies for that). I think the other stuff can be accomplished using netlink sockets + messages, no? >>> >>> Netlink sockets just used to communicate kernel-space - user-space, this is >>> not >>> why we need a kernel module, for example this communication is implemented >>> in >>> original KNI as part of FIFO. >>> The only trepidation I would have with something like this is the support from major vendors - out of tree modules are not generally supportable. Might be good to get some of the ethtool commands as netlink messages as well, then it is supportable with no 3rd party kernel modules. >>> >>> Yes, there is a out of three module problem for some distros, but >>> unfortunately >>> we are not able to find a solution for this case without an >>> external kernel module. >>> >>> This patch is still an RFC and if we receive suggested solution without a >>> kernel >>> module, we can work on it together. >> >> If it has to be in the kernel then you need to find a design that is >> upstreamable. Out of tree kernel modules are not a solution, they're a >> problem that people are working on eliminating. >> > > Hi Stephen, and other Linux experts in the mail list, > > Can you please help finding a upstreamable solution for kernel control path? > > Mainly what we are looking for is userspace network driver support in > kernel, similar to what FUSE does but a much simple version. > > Above KCP module basically does this, by having a network driver which > passing requests to userspace network driver, but it is not generic > enough. > > I wonder if it is possible make it more generic by extending rtnetlink > support: > 1- Add a new network driver to Linux (or update existing one like tun) > to forward requests, get responses. > 2- Extend rtnelink to support to attach any userspace driver to this > device? (ip link set uspace ?) > > Does this make sense? > > rtnetlink already supports creating interfaces, and it provides > kernel/user space communication, > with "attach" support interface learns about it's peer in usersppace > and can communicate. > > FUSE like communication method also can be alternative to transfer > request and responses, but since rtnelink support exists, no need to > create something new think. > > Thanks, > ferruh
[dpdk-dev] [PATCH 1/5] mempool: add external mempool manager support
Hi David,
Nice work, thanks !
Please see some comments below.
On 01/26/2016 06:25 PM, David Hunt wrote:
> diff --git a/lib/librte_mempool/rte_mempool.c
> b/lib/librte_mempool/rte_mempool.c
> index aff5f6d..8c01838 100644
> --- a/lib/librte_mempool/rte_mempool.c
> +++ b/lib/librte_mempool/rte_mempool.c
> @@ -375,48 +376,28 @@ rte_mempool_xmem_usage(void *vaddr, uint32_t elt_num,
> size_t elt_sz,
> return usz;
> }
>
> -#ifndef RTE_LIBRTE_XEN_DOM0
> -/* stub if DOM0 support not configured */
> -struct rte_mempool *
> -rte_dom0_mempool_create(const char *name __rte_unused,
> - unsigned n __rte_unused,
> - unsigned elt_size __rte_unused,
> - unsigned cache_size __rte_unused,
> - unsigned private_data_size __rte_unused,
> - rte_mempool_ctor_t *mp_init __rte_unused,
> - void *mp_init_arg __rte_unused,
> - rte_mempool_obj_ctor_t *obj_init __rte_unused,
> - void *obj_init_arg __rte_unused,
> - int socket_id __rte_unused,
> - unsigned flags __rte_unused)
> -{
> - rte_errno = EINVAL;
> - return NULL;
> -}
> -#endif
> -
Could we move this is a separated commit?
"mempool: remove unused rte_dom0_mempool_create stub"
> /* create the mempool */
> struct rte_mempool *
> rte_mempool_create(const char *name, unsigned n, unsigned elt_size,
> -unsigned cache_size, unsigned private_data_size,
> -rte_mempool_ctor_t *mp_init, void *mp_init_arg,
> -rte_mempool_obj_ctor_t *obj_init, void *obj_init_arg,
> -int socket_id, unsigned flags)
> + unsigned cache_size, unsigned private_data_size,
> + rte_mempool_ctor_t *mp_init, void *mp_init_arg,
> + rte_mempool_obj_ctor_t *obj_init, void *obj_init_arg,
> + int socket_id, unsigned flags)
> {
> if (rte_xen_dom0_supported())
> return rte_dom0_mempool_create(name, n, elt_size,
> -cache_size, private_data_size,
> -mp_init, mp_init_arg,
> -obj_init, obj_init_arg,
> -socket_id, flags);
> + cache_size, private_data_size,
> + mp_init, mp_init_arg,
> + obj_init, obj_init_arg,
> + socket_id, flags);
> else
> return rte_mempool_xmem_create(name, n, elt_size,
> -cache_size, private_data_size,
> -mp_init, mp_init_arg,
> -obj_init, obj_init_arg,
> -socket_id, flags,
> -NULL, NULL,
> MEMPOOL_PG_NUM_DEFAULT,
> -MEMPOOL_PG_SHIFT_MAX);
> + cache_size, private_data_size,
> + mp_init, mp_init_arg,
> + obj_init, obj_init_arg,
> + socket_id, flags,
> + NULL, NULL,
> + MEMPOOL_PG_NUM_DEFAULT, MEMPOOL_PG_SHIFT_MAX);
> }
As far as I can see, you are not modifying the code here, only the
style. For better readability, it should go in another commit that
only fixes indent or style issues.
Also, I think the proper indentation is to use only one tab for the
subsequent lines.
The coding style guide (doc/guides/contributing/coding_style.rst) is
not very clear about this however.
> @@ -469,7 +448,7 @@ rte_mempool_xmem_create(const char *name, unsigned n,
> unsigned elt_size,
>
> /* asked cache too big */
> if (cache_size > RTE_MEMPOOL_CACHE_MAX_SIZE ||
> - CALC_CACHE_FLUSHTHRESH(cache_size) > n) {
> + CALC_CACHE_FLUSHTHRESH(cache_size) > n) {
> rte_errno = EINVAL;
> return NULL;
> }
same here.
> @@ -598,6 +568,22 @@ rte_mempool_xmem_create(const char *name, unsigned n,
> unsigned elt_size,
> mp->cache_flushthresh = CALC_CACHE_FLUSHTHRESH(cache_size);
> mp->private_data_size = private_data_size;
>
> + /*
> + * Since we have 4 combinations of the SP/SC/MP/MC, and stack,
> + * examine the
> + * flags to set the correct index into the handler table.
> + */
nit: comment style is not correct
> + if (flags & MEMPOOL_F_USE_STACK)
> + mp->handler_idx = rte_get_mempool_handler("stack");
The stack handler does not exist yet, it is introduced in the next
commit. I think this code should be moved in the next commit too.
> @@ -622,6 +607,10 @@ rte_mempool_xmem_create(const char *name, unsigned n,
> unsigned elt_size,
>
> mp->elt_va_end = mp->elt_va_start;
>
>
[dpdk-dev] Fw: RE: DPDK vhostuser with vxlan# Does issue with igb_uio in ovs+dpdk setup
Hi All, The issue which we are facing as described in previous threads thats beccause of seting up ovs+dpdk with igb_uio driver instead of vfio_pci? Would appriciate if get any suggestions on this. Thanks & Regards Abhijeet Karve To: przemyslaw.czesnowicz at intel.com From: Abhijeet Karve Date: 01/30/2016 07:32PM Cc: "dev at dpdk.org" , "discuss at openvswitch.org" , "Gray, Mark D" Subject: Fw: RE: [dpdk-dev] DPDK vhostuser with vxlan Hi przemek, We have setup vxlan tunnel between our two compute nodes, Can see the traafic in vxlan port on br-tun of source instance's compute node. We are in same situation which is being described in below thread, i looked dev mailing archieves for it but seems no one has responded it. http://comments.gmane.org/gmane.linux.network.openvswitch.general/9878 Would be really appriciate if provide us any suggestions on it. Thanks & Regards Abhijeet Karve -Forwarded by on 01/30/2016 07:24PM - === To: "Czesnowicz, Przemyslaw" From: Abhijeet Karve/AHD/TCS at TCS Date: 01/27/2016 09:52PM Cc: "dev at dpdk.org" , "discuss at openvswitch.org" , "Gray, Mark D" Subject: RE: [dpdk-dev] DPDK OVS on Ubuntu 14.04# Issue's Resolved# Inter-VM communication & IP allocation through DHCP issue === Hi Przemek, Thanks for the quick response. Now able to get the DHCP ip's for 2 vhostuser instances and able to ping each other. Isssue was a bug in cirros 0.3.0 images which we were using in openstack after using 0.3.1 image as given in the URL(https://www.redhat.com/archives/rhos-list/2013-August/msg00032.html), able to get the IP's in vhostuser VM instances. As per our understanding, Packet flow across DPDK datapath will be like vhostuser ports are connected to the br-int bridge & same is being patched to the br-dpdk bridge where in our physical network (NIC) is connected with dpdk0 port. So for testing the flow we have to connect that physical network(NIC) with external packet generator (e.g - ixia, iperf) & run the testpmd application in the vhostuser VM, right? Does it required to add any flows/efforts in bridge configurations(either br-int or br-dpdk)? Thanks & Regards Abhijeet Karve From: "Czesnowicz, Przemyslaw" To: Abhijeet Karve Cc: "dev at dpdk.org" , "discuss at openvswitch.org" , "Gray, Mark D" Date: 01/27/2016 05:11 PM Subject: RE: [dpdk-dev] DPDK OVS on Ubuntu 14.04# Issue's Resolved# Inter-VM communication & IP allocation through DHCP issue Hi Abhijeet, It seems you are almost there! When booting the VM’s do you request hugepage memory for them (by setting hw:mem_page_size=large in flavor extra_spec)? If not then please do, if yes then please look into libvirt logfiles for the VM’s (in /var/log/libvirt/qemu/instance-xxx), I think there could be a clue. Regards Przemek From: Abhijeet Karve [mailto:abhijeet.ka...@tcs.com] Sent: Monday, January 25, 2016 6:13 PM To: Czesnowicz, Przemyslaw Cc: dev at dpdk.org; discuss at openvswitch.org; Gray, Mark D Subject: RE: [dpdk-dev] DPDK OVS on Ubuntu 14.04# Issue's Resolved# Inter-VM communication & IP allocation through DHCP issue Hi Przemek, Thank you for your response, It really provided us breakthrough. After setting up DPDK on compute node for stable/kilo, We are trying to set up Openstack stable/liberty all-in-one setup, At present we are not able to get the IP allocation for the vhost type instances through DHCP. Also we tried assigning IP's manually to them but the inter-VM communication also not happening, #neutron agent-list root at nfv-dpdk-devstack:/etc/neutron# neutron agent-list +--++---+---++---+ | id | agent_type | host | alive | admin_state_up | binary| +--++---+---++---+ | 3b29e93c-3a25-4f7d-bf6c-6bb309db5ec0 | DPDK OVS Agent | nfv-dpdk-devstack | :-) | True | neutron-openvswitch-agent | | 62593b2c-c10f-4d93-8551-c46ce24895a6 | L3 agent | nfv-dpdk-devstack | :-) | True | neutron-l3-agent | | 7cb97af9-cc20-41f8-90fb-aba97d39dfbd | DHCP agent | nfv-dpdk-devstack | :-) | True | neutron-dhcp-agent| | b613c654-99b7-437e-9317-20fa651a1310 | Linux bridge agent | nfv-dpdk-devstack | :-) | True | neutron-linuxbridge-agent | | c2dd0384-6517-4b44-9c25-0d2825d23f57 | Metadata agent | nfv-dpdk-devstack | :-) | True | neutron-metadata-agent| | f23dde40-7dc0-4f20-8b3e-eb90ddb15e49 | Open vSwitch agent | nfv-dpdk-devstack | xxx | True | neutron-openvswitch-agent | +--++---+---++---
[dpdk-dev] [PATCH 2/5] memool: add stack (lifo) based external mempool handler
Hi,
> [PATCH 2/5] memool: add stack (lifo) based external mempool handler
typo in the patch title: memool -> mempool
On 01/26/2016 06:25 PM, David Hunt wrote:
> adds a simple stack based mempool handler
>
> Signed-off-by: David Hunt
What is the purpose of this mempool handler?
Is it an example or is it something that could be useful for
dpdk applications?
If it's just an example, I think we could move this code
in app/test.
> --- a/app/test/test_mempool_perf.c
> +++ b/app/test/test_mempool_perf.c
> @@ -52,7 +52,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
Is this change related?
> +struct rte_mempool_common_stack {
> + /* Spinlock to protect access */
> + rte_spinlock_t sl;
> +
> + uint32_t size;
> + uint32_t len;
> + void *objs[];
> +
> +#ifdef RTE_LIBRTE_MEMPOOL_DEBUG
> +#endif
There is nothing inside the #ifdef
> +static void *
> +common_stack_alloc(struct rte_mempool *mp,
> + const char *name, unsigned n, int socket_id, unsigned flags)
> +{
> + struct rte_mempool_common_stack *s;
> + char stack_name[RTE_RING_NAMESIZE];
> +
> + int size = sizeof(*s) + (n+16)*sizeof(void *);
> +
> + flags = flags;
> +
> + /* Allocate our local memory structure */
> + snprintf(stack_name, sizeof(stack_name), "%s-common-stack", name);
> + s = rte_zmalloc_socket(stack_name,
> + size, RTE_CACHE_LINE_SIZE, socket_id);
> + if (s == NULL) {
> + RTE_LOG(ERR, MEMPOOL, "Cannot allocate stack!\n");
> + return NULL;
> + }
> +
> + /* And the spinlock we use to protect access */
> + rte_spinlock_init(&s->sl);
> +
> + s->size = n;
> + mp->rt_pool = (void *) s;
> + mp->handler_idx = rte_get_mempool_handler("stack");
> +
> + return (void *) s;
> +}
The explicit casts could be removed I think.
> +
> +static int common_stack_put(void *p, void * const *obj_table,
> + unsigned n)
> +{
> + struct rte_mempool_common_stack *s =
> + (struct rte_mempool_common_stack *)p;
indent issue (same in get() and count())
> + void **cache_objs;
> + unsigned index;
> +
> + /* Acquire lock */
> + rte_spinlock_lock(&s->sl);
> + cache_objs = &s->objs[s->len];
> +
> + /* Is there sufficient space in the stack ? */
> + if ((s->len + n) > s->size) {
> + rte_spinlock_unlock(&s->sl);
> + return -ENOENT;
> + }
I think this cannot happen as there is a check in the get().
I wonder if a rte_panic() wouldn't be better here.
Regards,
Olivier
[dpdk-dev] PING: [PATCH v2] pmd/virtio: fix cannot start virtio dev after stop
On Thu, Feb 04, 2016 at 01:29:19PM +0300, Pavel Fedin wrote: > Hello! Are there any news about this patch? We have got this problem for the > second time, it reproduces every time we try to use > ovs-dpdk inside virtual machine with virtio-net adapter. > > Kind regards, > Pavel Fedin > Senior Engineer > Samsung Electronics Research center Russia > > Commited to dpdk-next-net/rel_16_04 with added fixes line. /Bruce > > -Original Message- > > From: Jianfeng Tan [mailto:jianfeng.tan at intel.com] > > Sent: Monday, January 11, 2016 9:16 AM > > To: dev at dpdk.org > > Cc: p.fedin at samsung.com; yuanhan.liu at linux.intel.com; Jianfeng Tan > > Subject: [PATCH v2] pmd/virtio: fix cannot start virtio dev after stop > > > > v2 changes: > > - Address compiling error. > > - Add Reported-by. > > > > Fix the issue that virtio device cannot be started after stopped. > > > > The field, hw->started, should be changed by virtio_dev_start/stop instead > > of virtio_dev_close. > > > > Reported-by: Pavel Fedin > > Signed-off-by: Jianfeng Tan > > Acked-by: Yuanhan Liu > >
[dpdk-dev] [PATCH] fm10k: allocate logical ports for flow director
On Mon, Feb 01, 2016 at 07:40:12AM +, He, Shaopeng wrote: > > > -Original Message- > > From: Chen, Jing D > > Sent: Wednesday, December 30, 2015 4:36 PM > > To: dev at dpdk.org > > Cc: Yigit, Ferruh; He, Shaopeng; Chen, Jing D > > Subject: [PATCH] fm10k: allocate logical ports for flow director > > > > From: "Chen Jing D(Mark)" > > > > In fm10k, PF, VF, VMDQ or queues binding to flow director rule can > > be considered as a logical port. Original implementation only create > > single one for all cases. This change creates totally 128 logical > > ones, first 64 for PF and VMDQ, second 64 for flow director. > > > > Registers DGLORTDEC/DGLORTMAP define rules how to classify packets > > into different queues. Now only PF and VMDQ cases are considered. > > This change add rules for flow director. > > > > Signed-off-by: Chen Jing D(Mark) > Acked-by: Shaopeng He > Applied to dpdk-next-net/rel_16_04 Thanks, /Bruce
[dpdk-dev] [RFC 0/3] Use common Linux tools to control DPDK ports
On Thu, Feb 04, 2016 at 09:40:18AM -0500, Aaron Conole wrote: > Hi Ferruh, Hi Aaron, > > I missed your original reply to me. Sorry. > > Ferruh Yigit writes: > > On Tue, Jan 19, 2016 at 01:29:32PM +0200, Panu Matilainen wrote: > >> On 01/19/2016 11:59 AM, Ferruh Yigit wrote: > >>> On Mon, Jan 18, 2016 at 11:20:02AM -0500, Aaron Conole wrote: > Ferruh Yigit writes: > > This work is to make DPDK ports more visible and to enable using common > > Linux tools to configure DPDK ports. > > This is a good goal. Only question - why use an additional kernel module > to do this? Is it _JUST_ for ethtool support? > >>> > >>> Kernel module used to create/destroy Linux net_devices, and module has a > >>> simple > >>> driver for that device which only handles control messages by passing > >>> them into > >>> userspace. > >>> > >>> To represent DPDK ports as Linux net_devices we need kernel support. > > Why? Just create tun/tap interface, no? Then you get a queue into the > network stack, as well. Subscribe to netlink, and you can get all of the > changes that happen in the system - just look for those messages that > relate to your tun device. At least, that's what I see right away (and I > have some private patches for this, and you can take them over if you want). > Do you mean subscribe to rtnl messages, like "ip monitor" does? If so the problem with that is it is unidirectional, from kernel to userspace. Some operations can be applied with this method, still missing ability return status of action. But many can't be applied because userspace driver can't send data to kernel, like almost all ethtool commands requires information from userspace driver. In kernel side, an entity required to listen and handle userspace driver responses. > I think most of the stuff you are trying to solve already exists, but I > am probably misunderstanding something (apologies for that). > > I think the other stuff > can be accomplished using netlink sockets + messages, no? > >>> > >>> Netlink sockets just used to communicate kernel-space - user-space, this > >>> is not > >>> why we need a kernel module, for example this communication is > >>> implemented in > >>> original KNI as part of FIFO. > >>> > The only > trepidation I would have with something like this is the support from > major vendors - out of tree modules are not generally supportable. Might > be good to get some of the ethtool commands as netlink messages as well, > then it is supportable with no 3rd party kernel modules. > >>> > >>> Yes, there is a out of three module problem for some distros, but > >>> unfortunately > >>> we are not able to find a solution for this case without an > >>> external kernel module. > >>> > >>> This patch is still an RFC and if we receive suggested solution without a > >>> kernel > >>> module, we can work on it together. > >> > >> If it has to be in the kernel then you need to find a design that is > >> upstreamable. Out of tree kernel modules are not a solution, they're a > >> problem that people are working on eliminating. > >> > > > > Hi Stephen, and other Linux experts in the mail list, > > > > Can you please help finding a upstreamable solution for kernel control path? > > > > Mainly what we are looking for is userspace network driver support in > > kernel, similar to what FUSE does but a much simple version. > > > > Above KCP module basically does this, by having a network driver which > > passing requests to userspace network driver, but it is not generic > > enough. > > > > I wonder if it is possible make it more generic by extending rtnetlink > > support: > > 1- Add a new network driver to Linux (or update existing one like tun) > > to forward requests, get responses. > > 2- Extend rtnelink to support to attach any userspace driver to this > > device? (ip link set uspace ?) > > > > Does this make sense? > > > > rtnetlink already supports creating interfaces, and it provides > > kernel/user space communication, > > with "attach" support interface learns about it's peer in usersppace > > and can communicate. > > > > FUSE like communication method also can be alternative to transfer > > request and responses, but since rtnelink support exists, no need to > > create something new think. > > > > Thanks, > > ferruh
[dpdk-dev] [PATCH 1/5] mempool: add external mempool manager support
On 04/02/2016 14:52, Olivier MATZ wrote: > Hi David, > > Nice work, thanks ! > Please see some comments below. > > [snip] Olivier, Thanks for your comprehensive comments. I'm working on a v2 patch based on feedback already received from Jerin, and I'll be sure to include your feedback also. Many thanks, David.
[dpdk-dev] [PATCH v2] ip_pipeline: add load balancing function to pass-through pipeline
The pass-through pipeline implementation is extended with load balancing
function. This function allows uniform distribution of the packets among
its output ports. For packets distribution, any application level logic
can be applied. For instance, in this implementation, hash value
computed over specific header fields of the incoming packets has been
used to spread traffic uniformly among the output ports. The following
pass-through configuration can be used for implementing load balancing
function over ipv4 traffic;
[PIPELINE0]
type = PASS-THROUGH
core = 0
pktq_in = RXQ0.0 RXQ1.0 RXQ2.0 RXQ3.0
pktq_out = TXQ0.0 TXQ1.0 TXQ2.0 TXQ3.0
dma_src_offset = 278; mbuf (128) + headroom (128) + 1st ethertype offset (14) +
ttl offset within ip header = 278 (ipv4)
dma_dst_offset = 128; mbuf (128)
dma_size = 16
dma_src_mask = 00FF
dma_hash_offset = 144; (dma_dst_offset+dma_size)
lb = hash
Signed-off-by: Jasvinder Singh
Acked-by: Cristian Dumitrescu
---
v2
* modify the action handler implementation
.../ip_pipeline/pipeline/pipeline_actions_common.h | 22 ++
.../ip_pipeline/pipeline/pipeline_passthrough_be.c | 279 -
.../ip_pipeline/pipeline/pipeline_passthrough_be.h | 1 +
3 files changed, 236 insertions(+), 66 deletions(-)
diff --git a/examples/ip_pipeline/pipeline/pipeline_actions_common.h
b/examples/ip_pipeline/pipeline/pipeline_actions_common.h
index 9958758..ab08612 100644
--- a/examples/ip_pipeline/pipeline/pipeline_actions_common.h
+++ b/examples/ip_pipeline/pipeline/pipeline_actions_common.h
@@ -59,6 +59,28 @@ f_ah(
\
return 0; \
}
+#define PIPELINE_PORT_IN_AH_HIJACK_ALL(f_ah, f_pkt_work, f_pkt4_work) \
+static int \
+f_ah( \
+ struct rte_pipeline *p, \
+ struct rte_mbuf **pkts, \
+ uint32_t n_pkts,\
+ void *arg) \
+{ \
+ uint64_t pkt_mask = RTE_LEN2MASK(n_pkts, uint64_t); \
+ uint32_t i; \
+ \
+ rte_pipeline_ah_packet_hijack(p, pkt_mask); \
+ \
+ for (i = 0; i < (n_pkts & (~0x3LLU)); i += 4) \
+ f_pkt4_work(&pkts[i], arg); \
+ \
+ for ( ; i < n_pkts; i++)\
+ f_pkt_work(pkts[i], arg); \
+ \
+ return 0; \
+}
+
#define PIPELINE_TABLE_AH_HIT(f_ah, f_pkt_work, f_pkt4_work) \
static int \
f_ah( \
diff --git a/examples/ip_pipeline/pipeline/pipeline_passthrough_be.c
b/examples/ip_pipeline/pipeline/pipeline_passthrough_be.c
index 7642462..d2b1aa2 100644
--- a/examples/ip_pipeline/pipeline/pipeline_passthrough_be.c
+++ b/examples/ip_pipeline/pipeline/pipeline_passthrough_be.c
@@ -72,7 +72,9 @@ pkt_work(
struct rte_mbuf *pkt,
void *arg,
uint32_t dma_size,
- uint32_t hash_enabled)
+ uint32_t hash_enabled,
+ uint32_t lb_hash,
+ uint32_t port_out_pow2)
{
struct pipeline_passthrough *p = arg;
@@ -90,8 +92,24 @@ pkt_work(
dma_dst[i] = dma_src[i] & dma_mask[i];
/* Read (dma_dst), compute (hash), write (hash) */
- if (hash_enabled)
- *dma_hash = p->f_hash(dma_dst, dma_size, 0);
+ if (hash_enabled) {
+ uint32_t hash = p->f_hash(dma_dst, dma_size, 0);
+ *dma_hash = hash;
+
+ if (lb_hash) {
+ uint32_t port_out;
+
+ if (port_out_pow2)
+ port_out
+ = hash & (p->p.n_ports_out - 1);
+ else
+ port_out
+ = hash % p->p.n_ports_out;
+
+ rte_pipeline_port_out_packet_insert(p->p.p,
+ port_out, pkt);
+ }
+ }
}
static inline __attribute__((always_inline)) void
@@ -99,7 +117,9 @@ pkt4_work(
struct rte_mbuf **pkts,
void *arg,
uint32_t dma_size,
- uint32_t hash_enabled)
+
[dpdk-dev] [PATCH 1/5] mempool: add external mempool manager support
On 04/02/2016 14:52, Olivier MATZ wrote:
> Hi David,
[snip]
Just a comment on one of your comments:
> Why not using a similar mechanism than what we have for PMDs?
>
> void rte_eal_driver_register(struct rte_driver *driver)
> {
> TAILQ_INSERT_TAIL(&dev_driver_list, driver, next);
> }
>
> To do that, you just need to add a TAILQ_ENTRY() in your
> rte_mempool_handler structure. This would avoid to duplicate the
> structure into a static array whose size is limited.
>
> Accessing to the callbacks would be easier:
>
> return mp->mp_handler->put(mp->rt_pool, obj_table, n);
One of the iterations of the code did indeed use this mechanism, however
I ran into problems with multiple processes using the same mempool. In
that case, the 'mp_handler' element of the mempool in your return
statement is only valid for one of the processes. Hence the need for
and index that's valid for all processes rather than a pointer that's
valid for only one. And it's not easy to quickly index into an element
in a queue, hence the array of 16 mempool_handler structs.
[snip]
Rgds,
Dave.
[dpdk-dev] Fw: RE: DPDK vhostuser with vxlan# Does issue with igb_uio in ovs+dpdk setup
Hi Abhijeet, It looks to me that the arp entries may not populated right for the VxLAN ports in OVS. Can you please refer the debug section in http://openvswitch.org/support/config-cookbooks/userspace-tunneling/ to verify and insert right arp entries in case they are missing ?? Regards _Sugesh > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Abhijeet Karve > Sent: Thursday, February 4, 2016 2:55 PM > To: Czesnowicz, Przemyslaw > Cc: dev at dpdk.org; discuss at openvswitch.org > Subject: Re: [dpdk-dev] Fw: RE: DPDK vhostuser with vxlan# Does issue with > igb_uio in ovs+dpdk setup > > Hi All, > > The issue which we are facing as described in previous threads thats > beccause of seting up ovs+dpdk with igb_uio driver instead of vfio_pci? > > Would appriciate if get any suggestions on this. > > Thanks & Regards > Abhijeet Karve > > > To: przemyslaw.czesnowicz at intel.com > From: Abhijeet Karve > Date: 01/30/2016 07:32PM > Cc: "dev at dpdk.org" , "discuss at openvswitch.org" > , "Gray, Mark D" > Subject: Fw: RE: [dpdk-dev] DPDK vhostuser with vxlan > > > Hi przemek, > > > We have setup vxlan tunnel between our two compute nodes, Can see the > traafic in vxlan port on br-tun of source instance's compute node. > > We are in same situation which is being described in below thread, i looked > dev mailing archieves for it but seems no one has responded it. > > > http://comments.gmane.org/gmane.linux.network.openvswitch.general/98 > 78 > > Would be really appriciate if provide us any suggestions on it. > > > > Thanks & Regards > Abhijeet Karve > > -Forwarded by on 01/30/2016 07:24PM - > > === > To: "Czesnowicz, Przemyslaw" > From: Abhijeet Karve/AHD/TCS at TCS > Date: 01/27/2016 09:52PM > Cc: "dev at dpdk.org" , "discuss at openvswitch.org" > , "Gray, Mark D" > Subject: RE: [dpdk-dev] DPDK OVS on Ubuntu 14.04# Issue's Resolved# > Inter-VM communication & IP allocation through DHCP issue > === >Hi Przemek, > > Thanks for the quick response. Now able to get the DHCP ip's for 2 vhostuser > instances and able to ping each other. Isssue was a bug in cirros 0.3.0 images > which we were using in openstack after using 0.3.1 image as given in the > URL(https://www.redhat.com/archives/rhos-list/2013- > August/msg00032.html), able to get the IP's in vhostuser VM instances. > > As per our understanding, Packet flow across DPDK datapath will be like > vhostuser ports are connected to the br-int bridge & same is being patched > to the br-dpdk bridge where in our physical network (NIC) is connected with > dpdk0 port. > > So for testing the flow we have to connect that physical network(NIC) with > external packet generator (e.g - ixia, iperf) & run the testpmd application in > the vhostuser VM, right? > > Does it required to add any flows/efforts in bridge configurations(either br- > int or br-dpdk)? > > > Thanks & Regards > Abhijeet Karve > > > > > From: "Czesnowicz, Przemyslaw" > To: Abhijeet Karve > Cc: "dev at dpdk.org" , "discuss at openvswitch.org" > , "Gray, Mark D" > Date: 01/27/2016 05:11 PM > Subject: RE: [dpdk-dev] DPDK OVS on Ubuntu 14.04# Issue's Resolved# > Inter-VM communication & IP allocation through DHCP issue > > > > Hi Abhijeet, > > > It seems you are almost there! > When booting the VM’s do you request hugepage memory for them > (by setting hw:mem_page_size=large in flavor extra_spec)? > If not then please do, if yes then please look into libvirt logfiles for the > VM’s (in /var/log/libvirt/qemu/instance-xxx), I think there could be a > clue. > > > Regards > Przemek > > From: Abhijeet Karve [mailto:abhijeet.karve at tcs.com] > Sent: Monday, January 25, 2016 6:13 PM > To: Czesnowicz, Przemyslaw > Cc: dev at dpdk.org; discuss at openvswitch.org; Gray, Mark D > Subject: RE: [dpdk-dev] DPDK OVS on Ubuntu 14.04# Issue's Resolved# > Inter-VM communication & IP allocation through DHCP issue > > Hi Przemek, > > Thank you for your response, It really provided us breakthrough. > > After setting up DPDK on compute node for stable/kilo, We are trying to set > up Openstack stable/liberty all-in-one setup, At present we are not able to > get the IP allocation for the vhost type instances through DHCP. Also we tried > assigning IP's manually to them but the inter-VM communication also not > happening, > > #neutron agent-list > root at nfv-dpdk-devstack:/etc/neutron# neutron agent-list > +--++---+---+-- > --+---+ > | id | agent_type | host > | alive | admin_state_up > | binary| > +--++---+---+-- > --+---+ > | 3b29e93c-3a25-4f7d-bf6c-6bb309db5ec0 | DPDK OVS Agent | nfv-dpdk- > d
[dpdk-dev] [PATCH v2 5/6] ixgbe: support VxLAN & NVGRE TX checksum off-load
Hi Wenzhuo,
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Wenzhuo Lu
> Sent: Thursday, January 14, 2016 1:39 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v2 5/6] ixgbe: support VxLAN & NVGRE TX checksum
> off-load
>
> The patch add VxLAN & NVGRE TX checksum off-load. When the flag of
> outer IP header checksum offload is set, we'll set the context
> descriptor to enable this checksum off-load.
>
> Signed-off-by: Wenzhuo Lu
> ---
> drivers/net/ixgbe/ixgbe_rxtx.c | 52
> ++
> drivers/net/ixgbe/ixgbe_rxtx.h | 6 -
> lib/librte_mbuf/rte_mbuf.h | 2 ++
> 3 files changed, 49 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c b/drivers/net/ixgbe/ixgbe_rxtx.c
> index 512ac3a..fea2495 100644
> --- a/drivers/net/ixgbe/ixgbe_rxtx.c
> +++ b/drivers/net/ixgbe/ixgbe_rxtx.c
> @@ -85,7 +85,8 @@
> PKT_TX_VLAN_PKT |\
> PKT_TX_IP_CKSUM |\
> PKT_TX_L4_MASK | \
> - PKT_TX_TCP_SEG)
> + PKT_TX_TCP_SEG | \
> + PKT_TX_OUTER_IP_CKSUM)
I think you also need to update dev_info.tx_offload_capa,
couldn't find where you doing it.
>
> static inline struct rte_mbuf *
> rte_rxmbuf_alloc(struct rte_mempool *mp)
> @@ -364,9 +365,11 @@ ixgbe_set_xmit_ctx(struct ixgbe_tx_queue *txq,
> uint32_t ctx_idx;
> uint32_t vlan_macip_lens;
> union ixgbe_tx_offload tx_offload_mask;
> + uint32_t seqnum_seed = 0;
>
> ctx_idx = txq->ctx_curr;
> - tx_offload_mask.data = 0;
> + tx_offload_mask.data[0] = 0;
> + tx_offload_mask.data[1] = 0;
> type_tucmd_mlhl = 0;
>
> /* Specify which HW CTX to upload. */
> @@ -430,9 +433,20 @@ ixgbe_set_xmit_ctx(struct ixgbe_tx_queue *txq,
> }
> }
>
> + if (ol_flags & PKT_TX_OUTER_IP_CKSUM) {
> + tx_offload_mask.outer_l3_len |= ~0;
> + tx_offload_mask.outer_l2_len |= ~0;
> + seqnum_seed |= tx_offload.outer_l3_len
> +<< IXGBE_ADVTXD_OUTER_IPLEN;
> + seqnum_seed |= tx_offload.outer_l2_len
> +<< IXGBE_ADVTXD_TUNNEL_LEN;
> + }
I don't have an X550 card off-hand, but reading through datasheet - it doesn't
seem right.
When OUTER_IP_CKSUM is enabled MACLEN becomes outer_l2_len and
TUNNEL_LEN should be: outer_l4_len + tunnel_hdr_len + inner_l2_len.
So I think that in our case TUNNEL_LEN should be set to l2_len.
> +
> txq->ctx_cache[ctx_idx].flags = ol_flags;
> - txq->ctx_cache[ctx_idx].tx_offload.data =
> - tx_offload_mask.data & tx_offload.data;
> + txq->ctx_cache[ctx_idx].tx_offload.data[0] =
> + tx_offload_mask.data[0] & tx_offload.data[0];
> + txq->ctx_cache[ctx_idx].tx_offload.data[1] =
> + tx_offload_mask.data[1] & tx_offload.data[1];
> txq->ctx_cache[ctx_idx].tx_offload_mask= tx_offload_mask;
>
> ctx_txd->type_tucmd_mlhl = rte_cpu_to_le_32(type_tucmd_mlhl);
> @@ -441,7 +455,7 @@ ixgbe_set_xmit_ctx(struct ixgbe_tx_queue *txq,
> vlan_macip_lens |= ((uint32_t)tx_offload.vlan_tci <<
> IXGBE_ADVTXD_VLAN_SHIFT);
> ctx_txd->vlan_macip_lens = rte_cpu_to_le_32(vlan_macip_lens);
> ctx_txd->mss_l4len_idx = rte_cpu_to_le_32(mss_l4len_idx);
> - ctx_txd->seqnum_seed = 0;
> + ctx_txd->seqnum_seed = seqnum_seed;
> }
>
> /*
> @@ -454,16 +468,24 @@ what_advctx_update(struct ixgbe_tx_queue *txq, uint64_t
> flags,
> {
> /* If match with the current used context */
> if (likely((txq->ctx_cache[txq->ctx_curr].flags == flags) &&
> - (txq->ctx_cache[txq->ctx_curr].tx_offload.data ==
> - (txq->ctx_cache[txq->ctx_curr].tx_offload_mask.data &
> tx_offload.data {
> + (txq->ctx_cache[txq->ctx_curr].tx_offload.data[0] ==
> + (txq->ctx_cache[txq->ctx_curr].tx_offload_mask.data[0]
> + & tx_offload.data[0])) &&
> + (txq->ctx_cache[txq->ctx_curr].tx_offload.data[1] ==
> + (txq->ctx_cache[txq->ctx_curr].tx_offload_mask.data[1]
> + & tx_offload.data[1] {
> return txq->ctx_curr;
> }
>
> /* What if match with the next context */
> txq->ctx_curr ^= 1;
> if (likely((txq->ctx_cache[txq->ctx_curr].flags == flags) &&
> - (txq->ctx_cache[txq->ctx_curr].tx_offload.data ==
> - (txq->ctx_cache[txq->ctx_curr].tx_offload_mask.data &
> tx_offload.data {
> + (txq->ctx_cache[txq->ctx_curr].tx_offload.data[0] ==
> + (txq->ctx_cache[txq->ctx_curr].tx_offload_mask.data[0]
> + & tx_offload.data[0])) &&
> + (txq->ctx_cache[txq->ctx_curr].tx_offload.data[1] ==
> + (txq->ctx_cache[txq->ctx_curr].tx_offload_mask.data[1]
> + & tx_offload.data[
[dpdk-dev] [PATCH v2 4/6] ixgbe: support VxLAN & NVGRE RX checksum off-load
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Wenzhuo Lu
> Sent: Thursday, January 14, 2016 1:39 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v2 4/6] ixgbe: support VxLAN & NVGRE RX checksum
> off-load
>
> X550 will do VxLAN & NVGRE RX checksum off-load automatically.
> This patch exposes the result of the checksum off-load.
>
> Signed-off-by: Wenzhuo Lu
> ---
> drivers/net/ixgbe/ixgbe_rxtx.c | 11 ++-
> lib/librte_mbuf/rte_mbuf.c | 1 +
> lib/librte_mbuf/rte_mbuf.h | 1 +
> 3 files changed, 12 insertions(+), 1 deletion(-)
Do we need a new DEV_RX_OFFLOAD_ here?
>
> diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c b/drivers/net/ixgbe/ixgbe_rxtx.c
> index 52a263c..512ac3a 100644
> --- a/drivers/net/ixgbe/ixgbe_rxtx.c
> +++ b/drivers/net/ixgbe/ixgbe_rxtx.c
> @@ -1003,6 +1003,8 @@ rx_desc_status_to_pkt_flags(uint32_t rx_status)
> static inline uint64_t
> rx_desc_error_to_pkt_flags(uint32_t rx_status)
> {
> + uint64_t pkt_flags;
> +
> /*
>* Bit 31: IPE, IPv4 checksum error
>* Bit 30: L4I, L4I integrity error
> @@ -1011,8 +1013,15 @@ rx_desc_error_to_pkt_flags(uint32_t rx_status)
> 0, PKT_RX_L4_CKSUM_BAD, PKT_RX_IP_CKSUM_BAD,
> PKT_RX_IP_CKSUM_BAD | PKT_RX_L4_CKSUM_BAD
> };
> - return error_to_pkt_flags_map[(rx_status >>
> + pkt_flags = error_to_pkt_flags_map[(rx_status >>
> IXGBE_RXDADV_ERR_CKSUM_BIT) & IXGBE_RXDADV_ERR_CKSUM_MSK];
> +
> + if ((rx_status & IXGBE_RXD_STAT_OUTERIPCS) &&
> + (rx_status & IXGBE_RXDADV_ERR_OUTERIPER)) {
> + pkt_flags |= PKT_RX_OUTER_IP_CKSUM_BAD;
> + }
> +
> + return pkt_flags;
> }
>
> /*
> diff --git a/lib/librte_mbuf/rte_mbuf.c b/lib/librte_mbuf/rte_mbuf.c
> index c18b438..5d4af39 100644
> --- a/lib/librte_mbuf/rte_mbuf.c
> +++ b/lib/librte_mbuf/rte_mbuf.c
> @@ -260,6 +260,7 @@ const char *rte_get_rx_ol_flag_name(uint64_t mask)
> /* case PKT_RX_MAC_ERR: return "PKT_RX_MAC_ERR"; */
> case PKT_RX_IEEE1588_PTP: return "PKT_RX_IEEE1588_PTP";
> case PKT_RX_IEEE1588_TMST: return "PKT_RX_IEEE1588_TMST";
> + case PKT_RX_OUTER_IP_CKSUM_BAD: return "PKT_RX_OUTER_IP_CKSUM_BAD";
> default: return NULL;
> }
> }
> diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
> index f234ac9..5ad5e59 100644
> --- a/lib/librte_mbuf/rte_mbuf.h
> +++ b/lib/librte_mbuf/rte_mbuf.h
> @@ -98,6 +98,7 @@ extern "C" {
> #define PKT_RX_FDIR_ID (1ULL << 13) /**< FD id reported if FDIR match.
> */
> #define PKT_RX_FDIR_FLX (1ULL << 14) /**< Flexible bytes reported if
> FDIR match. */
> #define PKT_RX_QINQ_PKT (1ULL << 15) /**< RX packet with double VLAN
> stripped. */
> +#define PKT_RX_OUTER_IP_CKSUM_BAD (1ULL << 16) /**< Outer IP cksum of RX
> pkt. is not OK. */
There is
#define PKT_RX_EIP_CKSUM_BAD (0ULL << 0) /**< External IP header checksum
error. */
Probably need either redefine it, or remove it.
Konstantin
> /* add new RX flags here */
>
> /* add new TX flags here */
> --
> 1.9.3
[dpdk-dev] [PATCH] eal/x86: Fix build with clang for old AVX
2016-02-03 21:12, Zhihong Wang:
> When configuring RTE_MACHINE to "default", rte_memcpy implementation
> is the default one (old AVX).
> In this code, clang raises a warning thanks to -Wsometimes-uninitialized:
>
> rte_memcpy.h:838:6: error:
> variable 'srcofs' is used uninitialized whenever 'if' condition is false
> if (dstofss > 0) {
> ^~~
> rte_memcpy.h:849:6: note: uninitialized use occurs here
> if (srcofs == 0) {
> ^~
>
> It is fixed by moving srcofs initialization out of the condition.
> Also dstofss calculation is corrected.
>
> Fixes: 1ae817f9f887 ("eal/x86: tune memcpy for platforms without AVX512")
>
> Signed-off-by: Zhihong Wang
> Reported-by: De Lara Guarch, Pablo
Applied, thanks
[dpdk-dev] [PATCH v1] Modify and modularize l3fwd code
Hi Ravi, 2016-02-02 12:01, Kulasek, TomaszX: > Tested-by: Tomasz Kulasek > Acked-by: Tomasz Kulasek I'm sorry that another patch was applied before this one. Please could you rebase it? It is too big to do it myself safely. Thanks
[dpdk-dev] DPDK Community Call - Linux Foundation
Here are some brief minutes of our discussion on Tuesday. Apologies for the delay in sending these out. Attendees: Bob Monkman, Bruce Richardson, Dave Neary, Ferruh Yigit, Jim St Leger, John Bromhead, John McNamara, Keith Wiles, Konstantin Ananyev, Laura Kempke, M Jay, Martin Horne, Mike Dolan, Mike Glynn, Tetsuya Mukawa, Thomas Monjalon, Tim O'Driscoll, Yoshihiro Nakajima Note: This list is taken from the GoToMeeting tool, but since people joined/left at different times it may not be complete. The background to the call is that we had a discussion at the Userspace event in Dublin on using Linux Foundation to provide a lightweight governance model for DPDK. This would cover marketing, event planning, trademarks, other legal issues etc. It would not cover any technical governance of the project. Following this and a follow-up call we had in December, a small group of us (Dave Neary, Thomas Monjalon, Stephen Hemminger, Vincent Jardin, me) met with the Linux Foundation to create a draft budget which is available at: https://docs.google.com/spreadsheets/d/1-3686Xb_jf4FtxdX8Mus9UwIxUb2vI_ppmJV5GnXcLg/edit#gid=302618256. Laura walked through the spreadsheet at the meeting. Column B represents the minimum budget requirement for DPDK and totals $227k. Column C shows a number of optional additions and totals $766k. Points of discussion included: - The minimum option assumes that some of the event costs are covered by registration fees and sponsorship. - Jim asked about LF hosting DPDK IT infrastructure. This isn't currently included (row 23) but could be added if desired. - The item for hackathons (row 29) is just a placeholder. The general consensus seemed to be that we wouldn't need these. Taking the minimum budget requirement of ~$227k, that would mean we'd be looking for ~10-15 companies to contribute, each paying a flat-rate membership fee of ~$15-25k. There was a question on what member companies would get in return for their contribution. We need to do some further work on this, but the likelihood is that they would get a seat on a board which would determine how the DPDK budget is spent. The scope of this board would be limited to marketing/event/legal issues. Technical governance would continue to be handled separately via our Maintainers and our Architecture Board. Most people on the call felt that the proposal to use LF was a good idea and was worth pursuing further. However, we only had a small number of people on the call so that may not be representative of the views of the entire community. Therefore, if anybody has further thoughts or input on this, please feel free to reply to this email. Keith suggested holding a poll so that we can quantify the level of interest and give people a way to provide feedback anonymously in case they're unwilling to do so in public. I'll look into this. Feel free to post any corrections or additions if I missed anything. Tim > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of O'Driscoll, Tim > Sent: Saturday, January 23, 2016 12:19 AM > To: dev at dpdk.org > Subject: [dpdk-dev] DPDK Community Call - Linux Foundation > > At the community call we held on governance in December, we agreed that > a few of us would work with the Linux Foundation on a proposal for a > light-weight governance of DPDK. This would include things like > management of DPDK events, registering trademarks, and any required > legal support etc. > > Stephen, Thomas, Dave, Vincent and I met with the Linux Foundation to > discuss this and came up with a draft budget proposal. We'd like to have > a community call to discuss this and decide how we should proceed. > > The current budget estimate is ~$227k. LF guidance is that for this size > of budget they'd propose a flat membership fee (i.e. no tiered > membership) of ~$25k per member company, with a target of getting 10 or > more companies to contribute. > > At the call we can discuss: > - A breakdown of the proposed budget. LF are very flexible on this, so > we can add or remove whatever we want for DPDK. > - Proposed membership fee. > - Matthew also highlight some recent changes to community representation > at the Linux Foundation. We should discuss any concerns associated with > this. > - Next steps. > > > When: > Tue, Feb 2, 2015 15:00 - 16:00 GMT > Tue, Feb 2, 2015 07:00 - 08:00 PST > Tue, Feb 2, 2015 10:00 - 11:00 EST > Tue, Feb 2, 2015 16:00 - 17:00 CET > > > How to join: > You can join from a computer, tablet or smartphone: > https://global.gotomeeting.com/join/474154717 > > You can also dial in by phone. > Access Code: 474-154-717 > > More phone numbers > United States : +1 (312) 757-3126 > Australia : +61 2 9087 3604 > Austria : +43 7 2088 1400 > Belgium : +32 (0) 92 98 0592 > Canada : +1 (647) 497-9350 > Denmark : +45 69 91 80 05 > Finland : +358 (0) 942 41 5778 > France : +33 (0) 182 880 456 > Germany : +49 (0) 692 5736 7313 > Ireland : +353 (0) 15 290
