[dpdk-dev] [PATCH 02/10] examples/test-cxgbe-filters: add example to test cxgbe fdir support
Hi Bruce, On Wednesday, February 02/24/16, 2016 at 06:40:56 -0800, Bruce Richardson wrote: > On Wed, Feb 03, 2016 at 02:02:23PM +0530, Rahul Lakkireddy wrote: > > Add a new test_cxgbe_filters command line example to test support for > > Chelsio T5 hardware filtering. Shows how to pass the Chelsio input flow > > and input masks. Also, shows how to pass extra behavior arguments to > > rewrite fields in matched filter rules. > > > > Also add documentation and update MAINTAINERS. > > > > Signed-off-by: Rahul Lakkireddy > > Signed-off-by: Kumar Sanghvi > > Hi, > > for testing NIC functionality, the "testpmd" app is what is used, and it > already > contains support for existing flow director functionality. Should the testing > functionality not be included there? > We initially thought of adding example by extending flow director in testpmd itself. However, based on discussion at [1], we then created a separate sample app for this considering each vendor would come up with their own sample app. [1] http://permalink.gmane.org/gmane.comp.networking.dpdk.devel/31471 > Note: that's not to say we don't need a simple example app as well, for > demonstrating how to use flow director, but at minimum for nic features we > generally need to have testpmd support. > > Can this patchset perhaps be changed to include some testpmd support, and > maybe > have any example apps as a separate set? > If adding example in the existing testpmd sounds more appropriate then, I will re-submit by updating testpmd instead. Thanks, Rahul
[dpdk-dev] [PATCH 01/10] ethdev: add a generic flow and new behavior switch to fdir
Hi Thomas, On Wednesday, February 02/24/16, 2016 at 07:02:42 -0800, Thomas Monjalon wrote: > 2016-02-24 14:43, Bruce Richardson: > > On Wed, Feb 03, 2016 at 02:02:22PM +0530, Rahul Lakkireddy wrote: > > > Add a new raw packet flow that allows specifying generic flow input. > > > > > > Add the ability to provide masks for fields in flow to allow range of > > > values. > > > > > > Add a new behavior switch. > > > > > > Add the ability to provide behavior arguments to allow rewriting matched > > > fields with new values. Ex: allows to provide new ip and port addresses > > > to rewrite the fields of packets matching a filter rule before NAT'ing. > > > > > Thomas, any comments as ethdev maintainer? > > Yes, some comments. > First, there are several different changes in the same patch. It must be > split. Should each structure change be split into a separate patch? > Then I don't understand at all the raw flow filter. What is a raw flow? > How behavior_arg must be used? > This was discussed with Jingjing at http://permalink.gmane.org/gmane.comp.networking.dpdk.devel/31471 A raw flow provides a generic way for vendors to add their vendor specific input flow. In our case, it is possible to match several flows in a single rule. For example, it's possible to set an ethernet, vlan, ip and tcp/udp flows all in a single rule. We can specify all of these flows in a single raw input flow, which can then be passed to cxgbe flow director to set the corresponding filter. On similar lines, behavior_arg provides a generic way to pass extra action arguments for matched flows. For example, in our case, to perform NAT, the new src/dst ip and src/dst port addresses to be re-written for a matched rule can be passed in behavior_arg. Thanks, Rahul
[dpdk-dev] [PATCH] enic: fix dma addr of outgoing packets
The enic PMD driver send function uses a constant offset instead
of relying on the data_off in the mbuf to find the start of the packet.
Signed-off-by: Yoann Desmouceaux
---
drivers/net/enic/enic_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/enic/enic_main.c b/drivers/net/enic/enic_main.c
index 07a9810..f818c32 100644
--- a/drivers/net/enic/enic_main.c
+++ b/drivers/net/enic/enic_main.c
@@ -166,7 +166,7 @@ void enic_send_pkt(struct enic *enic, struct vnic_wq *wq,
uint16_t mss = 0;
uint8_t vlan_tag_insert = 0;
uint64_t bus_addr = (dma_addr_t)
- (tx_pkt->buf_physaddr + RTE_PKTMBUF_HEADROOM);
+ (tx_pkt->buf_physaddr + tx_pkt->data_off);
if (sop) {
if (ol_flags & PKT_TX_VLAN_PKT)
--
2.1.4
[dpdk-dev] [PATCH v2] i40e: add VEB switching support for i40e
> -Original Message- > From: Tao, Zhe > Sent: Tuesday, February 23, 2016 4:11 PM > To: dev at dpdk.org > Cc: Tao, Zhe; Wu, Jingjing > Subject: [dpdk-dev][PATCH v2] i40e: add VEB switching support for i40e > > Signed-off-by: Zhe Tao > > VEB switching feature for i40e is used to enable the switching between the > VSIs connect to the virtual bridge. The old implementation is setting the > virtual bridge mode as VEPA which is port aggregation. Enable the switching > ability by setting the loop back mode for the specific VSIs which connect to > PF > or VFs. > > v1: Add the VEB switching support. > v2: Add the check for the FW version,which should larger than 5.0. > Add release note. > --- > doc/guides/rel_notes/release_16_04.rst | 1 + > drivers/net/i40e/i40e_ethdev.c | 57 > +- > 2 files changed, 50 insertions(+), 8 deletions(-) > > diff --git a/doc/guides/rel_notes/release_16_04.rst > b/doc/guides/rel_notes/release_16_04.rst > index 5786f74..eb7effc 100644 > --- a/doc/guides/rel_notes/release_16_04.rst > +++ b/doc/guides/rel_notes/release_16_04.rst > @@ -46,6 +46,7 @@ This section should contain new features added in this Acked-by: Jingjing Wu With minor suggestion: v1/v2 changes need to be put after ---
[dpdk-dev] [PATCH 1/2 v2] i40e: support floating VEB config
> @@ -68,6 +68,7 @@ struct internal_config {
> volatile unsigned xen_dom0_support; /**< support app running on
> Xen Dom0*/
> volatile unsigned no_pci; /**< true to disable PCI */
> volatile unsigned no_hpet;/**< true to disable HPET */
> + volatile unsigned floating; /**< true to disable floating VEB */
true to disable( -> enable) floating VEB.
> volatile unsigned vmware_tsc_map; /**< true to use VMware TSC
> mapping
>
> * instead of native TSC */
> volatile unsigned no_shconf; /**< true if there is no shared config
> */
> diff --git a/lib/librte_eal/common/eal_options.h
> b/lib/librte_eal/common/eal_options.h
> index a881c62..413c9e6 100644
> --- a/lib/librte_eal/common/eal_options.h
> +++ b/lib/librte_eal/common/eal_options.h
> @@ -83,6 +83,8 @@ enum {
> OPT_VMWARE_TSC_MAP_NUM,
> #define OPT_XEN_DOM0 "xen-dom0"
> OPT_XEN_DOM0_NUM,
> +#define OPT_FLOATING "floating"
> + OPT_FLOATING_NUM,
> OPT_LONG_MAX_NUM
> };
>
New option is added, any doc to update?
> --
> 2.1.4
[dpdk-dev] [PATCH 2/2 v2] i40e: Add floating VEB support in i40e
> if (ret != I40E_SUCCESS) {
> PMD_DRV_LOG(ERR, "Add veb failed, aq_err: %d", @@ -
> 3688,20 +3702,21 @@ i40e_vsi_release(struct i40e_vsi *vsi)
> i40e_veb_release(vsi->veb);
> }
>
> + if (vsi->floating_veb) {
> + TAILQ_FOREACH(vsi_list, &vsi->floating_veb->head, list) {
> + if (i40e_vsi_release(vsi_list->vsi) != I40E_SUCCESS)
> + return -1;
> + TAILQ_REMOVE(&vsi->floating_veb->head, vsi_list,
> list);
> + }
> + i40e_veb_release(vsi->floating_veb);
> + }
> +
> /* Remove all macvlan filters of the VSI */
> i40e_vsi_remove_all_macvlan_filter(vsi);
> TAILQ_FOREACH(f, &vsi->mac_list, next)
> rte_free(f);
>
> if (vsi->type != I40E_VSI_MAIN) {
> - /* Remove vsi from parent's sibling list */
> - if (vsi->parent_vsi == NULL || vsi->parent_vsi->veb == NULL)
> {
> - PMD_DRV_LOG(ERR, "VSI's parent VSI is NULL");
> - return I40E_ERR_PARAM;
> - }
> - TAILQ_REMOVE(&vsi->parent_vsi->veb->head,
> - &vsi->sib_vsi_list, list);
Why do you think these line is unnecessary? We need to remove it from vsi list.
> -
> /* Remove all switch element of the VSI */
> ret = i40e_aq_delete_element(hw, vsi->seid, NULL);
> if (ret != I40E_SUCCESS)
> @@ -3837,7 +3852,8 @@ i40e_vsi_setup(struct i40e_pf *pf,
> struct ether_addr broadcast =
> {.addr_bytes = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff}};
>
> - if (type != I40E_VSI_MAIN && uplink_vsi == NULL) {
> + if (type != I40E_VSI_MAIN && type != I40E_VSI_SRIOV &&
> + uplink_vsi == NULL) {
> PMD_DRV_LOG(ERR, "VSI setup failed, "
> "VSI link shouldn't be NULL");
> return NULL;
> @@ -3849,11 +3865,28 @@ i40e_vsi_setup(struct i40e_pf *pf,
> return NULL;
> }
>
> - /* If uplink vsi didn't setup VEB, create one first */
> - if (type != I40E_VSI_MAIN && uplink_vsi->veb == NULL) {
> + /* two situations
> + * 1.type is not MAIN and uplink vsi is not NULL
> + * If uplink vsi didn't setup VEB, create one first under veb field
> + * 2.type is SRIOV and the uplink is NULL
> + * If floating VEB is NULL, create one veb under floating veb field
> + */
> +
> + if (type != I40E_VSI_MAIN && uplink_vsi != NULL &&
> + uplink_vsi->veb == NULL) {
> uplink_vsi->veb = i40e_veb_setup(pf, uplink_vsi);
>
> - if (NULL == uplink_vsi->veb) {
> + if (uplink_vsi->veb == NULL) {
> + PMD_DRV_LOG(ERR, "VEB setup failed");
> + return NULL;
> + }
> + }
> +
> + if (type == I40E_VSI_SRIOV && uplink_vsi == NULL &&
> + pf->main_vsi->floating_veb == NULL) {
> + pf->main_vsi->floating_veb = i40e_veb_setup(pf, uplink_vsi);
> +
> + if (pf->main_vsi->floating_veb == NULL) {
> PMD_DRV_LOG(ERR, "VEB setup failed");
> return NULL;
> }
> @@ -4022,7 +4055,11 @@ i40e_vsi_setup(struct i40e_pf *pf,
>* For other VSI, the uplink_seid equals to uplink VSI's
>* uplink_seid since they share same VEB
>*/
> - vsi->uplink_seid = uplink_vsi->uplink_seid;
> + if (uplink_vsi == NULL) {
> + vsi->uplink_seid = pf->main_vsi->floating_veb->seid;
> + } else {
> + vsi->uplink_seid = uplink_vsi->uplink_seid;
> + }
{} is not necessary.
> ctxt.pf_num = hw->pf_id;
> ctxt.vf_num = hw->func_caps.vf_base_id + user_param;
> ctxt.uplink_seid = vsi->uplink_seid;
> @@ -4130,8 +4167,13 @@ i40e_vsi_setup(struct i40e_pf *pf,
> vsi->seid = ctxt.seid;
> vsi->vsi_id = ctxt.vsi_number;
> vsi->sib_vsi_list.vsi = vsi;
> - TAILQ_INSERT_TAIL(&uplink_vsi->veb->head,
> - &vsi->sib_vsi_list, list);
> + if (vsi->type == I40E_VSI_SRIOV && uplink_vsi == NULL) {
> + TAILQ_INSERT_TAIL(&pf->main_vsi->floating_veb-
> >head,
> + &vsi->sib_vsi_list, list);
> + } else {
> + TAILQ_INSERT_TAIL(&uplink_vsi->veb->head,
> + &vsi->sib_vsi_list, list);
> + }
> }
>
> /* MAC/VLAN configuration */
> diff --git a/drivers/net/i40e/i40e_ethdev.h
> b/drivers/net/i40e/i40e_ethdev.h index 6edd7dd..19246db 100644
> --- a/drivers/net/i40e/i40e_ethdev.h
> +++ b/drivers/net/i40e/i40e_ethdev.h
> @@ -36,6 +36,7 @@
>
> #include
> #include
> +#include
>
> #define I40E_VLAN_TAG_SIZE4
>
> @@ -203,6 +204,7 @@
[dpdk-dev] [PATCH v2] ixgbe: fix link down issue on x550em_x
Hi Bruce, > -Original Message- > From: Richardson, Bruce > Sent: Wednesday, February 24, 2016 10:26 PM > To: He, Shaopeng > Cc: Lu, Wenzhuo; dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH v2] ixgbe: fix link down issue on x550em_x > > On Thu, Feb 04, 2016 at 06:21:04AM +, He, Shaopeng wrote: > > > > > -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 > > > I'm a bit confused regarding the commit message and the code in the patch. > The commit message talks about enabling speed auto-negotiation, while the > code never refers to any such thing. Instead all we have are settings for > manipulating interrupt masks to enable PHY interrupts. I think some additional > information is needed to connect A and B together here. The reason is that the handler of the link speed auto-neg is already in the base code. It's ixgbe_handle_lasi. What we need is a trigger. When the advertised link speed changes, a PHY interruption will be triggered. So, we should handle this interruption and call ixgbe_handle_lasi to set the link speed correct. Let me add more explanation in the commit log. > > A second, more minor nit is that the commit title never refers to link auto- > negotiation, but refers to this as a bug fix - which is also correct. If this > is > primarily a bug fix, please include a fixes line if possible, but please also > refer to > auto-neg in the title if possible too. I didn't add a fixes line because it doesn't fix an issue introduced by SW, or even FW, HW. As said in commit log, we hit a link down issue, but the root cause is the link speed auto-neg is not supported on this specific NIC. On the other NICs, link speed auto-neg is supported by FW, SW need no do anything. So we didn't implement the link speed auto-neg. But we have to implement this feature on this NIC for FW doesn't implement it. Should I change the tittle to "support link speed auto-neg on x550em_x"? > > /Bruce
[dpdk-dev] [PATCH v2] ixgbe: fix link down issue on x550em_x
Hi Bruce, > -Original Message- > From: Richardson, Bruce > Sent: Wednesday, February 24, 2016 10:27 PM > To: Lu, Wenzhuo > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH v2] ixgbe: fix link down issue on x550em_x > > On Mon, Feb 01, 2016 at 04:42:39PM +0800, Wenzhuo Lu wrote: > > 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 > > --- > > doc/guides/rel_notes/release_2_3.rst | 6 ++ > > drivers/net/ixgbe/ixgbe_ethdev.c | 38 > > > drivers/net/ixgbe/ixgbe_ethdev.h | 1 + > > 3 files changed, 45 insertions(+) > > > > diff --git a/doc/guides/rel_notes/release_2_3.rst > > b/doc/guides/rel_notes/release_2_3.rst > > index 99de186..a8d34d1 100644 > > --- a/doc/guides/rel_notes/release_2_3.rst > > +++ b/doc/guides/rel_notes/release_2_3.rst > > @@ -15,6 +15,12 @@ EAL > > Drivers > > ~~~ > > > > +* **ixgbe: fix link down issue on X550EM_X.** > > + Normally the auto-negotiation is supported by FW. SW need not care > > +about > > + that. But on x550em_x, FW doesn't support auto-neg. As the ports of > > +x550em_x > > + are 10G, if we connect the port will a peer which is 1G, the link > > +will always > > + be donw on x550em_x. > > + We will support auto-neg by SW to avoid this link down issue. > > > > Couple of typos present in the text above. Sorry for that. I'll correct them. Thanks. > > /Bruce
[dpdk-dev] [PATCH v5 3/4] driver/i40e: implement tunnel filter for IP in GRE
> @@ -5833,16 +5839,22 @@ i40e_dev_tunnel_filter_set(struct i40e_pf *pf,
> (void)rte_memcpy(&pfilter->inner_mac, &tunnel_filter->inner_mac,
> ETHER_ADDR_LEN);
>
> - pfilter->inner_vlan = tunnel_filter->inner_vlan;
> + pfilter->inner_vlan = rte_cpu_to_le_16(tunnel_filter->inner_vlan);
> if (tunnel_filter->ip_type == RTE_TUNNEL_IPTYPE_IPV4) {
> ip_type = I40E_AQC_ADD_CLOUD_FLAGS_IPV4;
> + tunnel_filter->ip_addr.ipv4_addr =
> + rte_cpu_to_le_32(tunnel_filter->ip_addr.ipv4_addr);
> (void)rte_memcpy(&pfilter->ipaddr.v4.data,
> - &tunnel_filter->ip_addr,
> + &tunnel_filter->ip_addr.ipv4_addr,
> sizeof(pfilter->ipaddr.v4.data));
> } else {
> ip_type = I40E_AQC_ADD_CLOUD_FLAGS_IPV6;
> + for (i = 0; i < 4; i++) {
> + tunnel_filter->ip_addr.ipv6_addr[i] =
> + rte_cpu_to_le_32(tunnel_filter-
> >ip_addr.ipv6_addr[i]);
You changed the value of in parameter.
It's better to use an internal variable to convert byte order.
Thanks
Jingjing
> 1.9.3
[dpdk-dev] [PATCH] doc: Malicious Driver Detection not supported by ixgbe
Hi Stephen, > -Original Message- > From: Stephen Hemminger [mailto:stephen at networkplumber.org] > Sent: Thursday, February 25, 2016 1:04 AM > To: Lu, Wenzhuo > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH] doc: Malicious Driver Detection not supported > by ixgbe > > On Wed, 24 Feb 2016 13:33:04 +0800 > Wenzhuo Lu wrote: > > > + On Intel x550 series NICs, HW supports a feature called MDD > > + (Malcicious Driver Detection). > > + MDD is used to check the behavior of the VF driver. It means when > > + transmitting packets, the VF must use the advanced context descriptor and > set it correctly. > > + And VF must set the CC (Check Context) bit either. > > This is hard sentence to read, why not reword as: > > The Intel x550 series NIC's support1 a feature called MDD (Malcicious Driver > Detection) which checks the behavior of the VF driver. > If this feature is enabled, the VF must use the advanced context descriptor > correctly and set the CC (Check Context) bit. Thanks for the suggestion. I'll try to make it better :) > > > > + DPDK PF doesn't support MDD. We may hit problem in this scenario > > + kernel PF + DPDK VF. If user enables MDD in kernel PF, DPDK VF will > > + not work. Because kernel PF thinks the VF is malicious. But > > + actually it's not. The only reason is the VF doesn't act as MDD required. > > + There's significant performance impact to support MDD. DPDK should > > + check if the advanced context descriptor should be set and set it. > > + And DPDK has to ask the info about the header length from the upper > > + layer, because parsing the packet itself is not acceptale. So, it's too > expensive to support MDD. > > + When using kernel PF + DPDK VF on x550, please make sure using the > > + kernel driver that disables MDD or can disable MDD. (Some kernel > > + driver can use this CLI 'insmod ixgbe.ko MDD=0,0' to disable MDD. > > + Some kernel driver disable it by default.) > > +
[dpdk-dev] [PATCH v5 1/4] lib/ether: optimize the'rte_eth_tunnel_filter_conf' structure
> -Original Message-
> From: Sun, Xutao
> Sent: Friday, February 19, 2016 3:32 PM
> To: dev at dpdk.org
> Cc: Zhang, Helin; Wu, Jingjing; De Lara Guarch, Pablo; Sun, Xutao; Liu,
> Jijiang
> Subject: [PATCH v5 1/4] lib/ether: optimize the'rte_eth_tunnel_filter_conf'
> structure
>
> Change the fields of outer_mac and inner_mac from pointer to struct in
> order to keep the code's readability.
>
> Signed-off-by: Xutao Sun
> Signed-off-by: Jijiang Liu
> diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> index a520cc5..3ee629a 100644
> --- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> +++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> @@ -553,7 +553,37 @@ tunnel_filter add
> Add a tunnel filter on a port::
>
> testpmd> tunnel_filter add (port_id) (outer_mac) (inner_mac) (ip_addr) \
> -(inner_vlan) (tunnel_type) (filter_type) (tenant_id) (queue_id)
> +(inner_vlan) (vxlan|nvgre|ipingre) (imac-ivlan|imac-ivlan-tenid|\
> +imac-tenid|imac|omac-imac-tenid|oip|iip) (tenant_id)
> + (queue_id)
> +
> +The available information categories are:
> +
> +* ``vxlan``: Set tunnel type as VXLAN.
> +
> +* ``nvgre``: Set tunnel type as NVGRE.
> +
> +* ``ipingre``: Set tunnel type as IP-in-GRE.
> +
> +* ``imac-ivlan``: Set filter type as Inner MAC and VLAN.
> +
> +* ``imac-ivlan-tenid``: Set filter type as Inner MAC, VLAN and tenant ID.
> +
> +* ``imac-tenid``: Set filter type as Inner MAC and tenant ID.
> +
> +* ``imac``: Set filter type as Inner MAC.
> +
> +* ``omac-imac-tenid``: Set filter type as Outer MAC, Inner MAC and tenant
> ID.
> +
> +* ``oip``: Set filter type as Outer IP.
> +
> +* ``iip``: Set filter type as Inner IP.
> +
Doc for tunnel_filter is extended, and ipingre type is also mentioned here.
This part seems no relationship with the commit log "Change the fields of
outer_mac
and inner_mac from pointer to struct in order to keep the code's readability".
It's better to move to latter patch.
> +Example::
> +
> + testpmd> tunnel_filter add 0 68:05:CA:28:09:82 00:00:00:00:00:00 \
> +192.168.2.2 0 ipingre oip 1 1
> +
> + Set an IP-in-GRE tunnel on port 0, and the filter type is Outer IP.
>
> tunnel_filter remove
>
> @@ -561,7 +591,8 @@ tunnel_filter remove Remove a tunnel filter on a
> port::
>
> testpmd> tunnel_filter rm (port_id) (outer_mac) (inner_mac) (ip_addr) \
> -(inner_vlan) (tunnel_type) (filter_type) (tenant_id) (queue_id)
> +(inner_vlan) (vxlan|nvgre|ipingre) (imac-ivlan|imac-ivlan-tenid|\
> +imac-tenid|imac|omac-imac-tenid|oip|iip) (tenant_id)
> + (queue_id)
>
> rx_vxlan_port add
> ~
> diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
> index ef24122..7c22358 100644
> --- a/drivers/net/i40e/i40e_ethdev.c
> +++ b/drivers/net/i40e/i40e_ethdev.c
> @@ -5828,10 +5828,10 @@ i40e_dev_tunnel_filter_set(struct i40e_pf *pf,
> }
> pfilter = cld_filter;
>
> - (void)rte_memcpy(&pfilter->outer_mac, tunnel_filter->outer_mac,
> - sizeof(struct ether_addr));
> - (void)rte_memcpy(&pfilter->inner_mac, tunnel_filter->inner_mac,
> - sizeof(struct ether_addr));
> + (void)rte_memcpy(&pfilter->outer_mac, &tunnel_filter->outer_mac,
> + ETHER_ADDR_LEN);
> + (void)rte_memcpy(&pfilter->inner_mac, &tunnel_filter->inner_mac,
> + ETHER_ADDR_LEN);
>
> pfilter->inner_vlan = tunnel_filter->inner_vlan;
> if (tunnel_filter->ip_type == RTE_TUNNEL_IPTYPE_IPV4) { @@ -
> 6131,13 +6131,13 @@ i40e_tunnel_filter_param_check(struct i40e_pf *pf,
> }
>
> if ((filter->filter_type & ETH_TUNNEL_FILTER_OMAC) &&
> - (is_zero_ether_addr(filter->outer_mac))) {
> + (is_zero_ether_addr(&filter->outer_mac))) {
> PMD_DRV_LOG(ERR, "Cannot add NULL outer MAC
> address");
> return -EINVAL;
> }
>
> if ((filter->filter_type & ETH_TUNNEL_FILTER_IMAC) &&
> - (is_zero_ether_addr(filter->inner_mac))) {
> + (is_zero_ether_addr(&filter->inner_mac))) {
> PMD_DRV_LOG(ERR, "Cannot add NULL inner MAC address");
> return -EINVAL;
> }
> diff --git a/lib/librte_ether/rte_eth_ctrl.h b/lib/librte_ether/rte_eth_ctrl.h
> index ce224ad..30cbde7 100644
> --- a/lib/librte_ether/rte_eth_ctrl.h
> +++ b/lib/librte_ether/rte_eth_ctrl.h
> @@ -280,8 +280,8 @@ enum rte_tunnel_iptype {
> * Tunneling Packet filter configuration.
> */
> struct rte_eth_tunnel_filter_conf {
> - struct ether_addr *outer_mac; /**< Outer MAC address filter. */
> - struct ether_addr *inner_mac; /**< Inner MAC address filter. */
> + struct ether_addr outer_mac; /**< Outer MAC address filter. */
> + struct ether_addr inner_mac; /**< Inner MAC address filter. */
> uint16_t inner_vlan; /**<
[dpdk-dev] [PATCH 01/10] ethdev: add a generic flow and new behavior switch to fdir
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Rahul Lakkireddy
> Sent: Wednesday, February 03, 2016 4:32 PM
> To: dev at dpdk.org
> Cc: Kumar Sanghvi; Nirranjan Kirubaharan
> Subject: [dpdk-dev] [PATCH 01/10] ethdev: add a generic flow and new
> behavior switch to fdir
>
> Add a new raw packet flow that allows specifying generic flow input.
>
> Add the ability to provide masks for fields in flow to allow range of values.
>
> Add a new behavior switch.
>
> Add the ability to provide behavior arguments to allow rewriting matched
> fields with new values. Ex: allows to provide new ip and port addresses to
> rewrite the fields of packets matching a filter rule before NAT'ing.
>
> Signed-off-by: Rahul Lakkireddy
> Signed-off-by: Kumar Sanghvi
> ---
> doc/guides/rel_notes/release_2_3.rst | 3 +++
> lib/librte_ether/rte_eth_ctrl.h | 15 ++-
> 2 files changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/doc/guides/rel_notes/release_2_3.rst
> b/doc/guides/rel_notes/release_2_3.rst
> index 99de186..19ce954 100644
> --- a/doc/guides/rel_notes/release_2_3.rst
> +++ b/doc/guides/rel_notes/release_2_3.rst
> @@ -39,6 +39,9 @@ API Changes
> ABI Changes
> ---
>
> +* New flow type ``RTE_ETH_FLOW_RAW_PKT`` had been introduced and
> hence
> + ``RTE_ETH_FLOW_MAX`` had been increased to 19.
> +
>
Great to see a raw_pkt_flow type.
And there is already a flow type "RTE_ETH_FLOW_RAW", it's not necessary to add
a new one.
> Shared Library Versions
> ---
> diff --git a/lib/librte_ether/rte_eth_ctrl.h b/lib/librte_ether/rte_eth_ctrl.h
> index ce224ad..1bc0d03 100644
> --- a/lib/librte_ether/rte_eth_ctrl.h
> +++ b/lib/librte_ether/rte_eth_ctrl.h
> @@ -74,7 +74,8 @@ extern "C" {
> #define RTE_ETH_FLOW_IPV6_EX15
> #define RTE_ETH_FLOW_IPV6_TCP_EX16
> #define RTE_ETH_FLOW_IPV6_UDP_EX17
> -#define RTE_ETH_FLOW_MAX18
> +#define RTE_ETH_FLOW_RAW_PKT18
> +#define RTE_ETH_FLOW_MAX19
>
> /**
> * Feature filter types
> @@ -499,6 +500,9 @@ struct rte_eth_tunnel_flow {
> struct ether_addr mac_addr;/**< Mac address to match. */
> };
>
> +/**< Max length of raw packet in bytes. */ #define
> +RTE_ETH_RAW_PKT_FLOW_MAX_LEN 256
> +
> /**
> * An union contains the inputs for all types of flow
> */
> @@ -514,6 +518,7 @@ union rte_eth_fdir_flow {
> struct rte_eth_ipv6_flow ipv6_flow;
> struct rte_eth_mac_vlan_flow mac_vlan_flow;
> struct rte_eth_tunnel_flow tunnel_flow;
> + uint8_t raw_pkt_flow[RTE_ETH_RAW_PKT_FLOW_MAX_LEN];
> };
>
> /**
> @@ -534,6 +539,8 @@ struct rte_eth_fdir_input {
> uint16_t flow_type;
> union rte_eth_fdir_flow flow;
> /**< Flow fields to match, dependent on flow_type */
> + union rte_eth_fdir_flow flow_mask;
> + /**< Mask for the fields matched, dependent on flow */
> struct rte_eth_fdir_flow_ext flow_ext;
> /**< Additional fields to match */
> };
> @@ -545,6 +552,7 @@ enum rte_eth_fdir_behavior {
> RTE_ETH_FDIR_ACCEPT = 0,
> RTE_ETH_FDIR_REJECT,
> RTE_ETH_FDIR_PASSTHRU,
> + RTE_ETH_FDIR_SWITCH,
> };
>
> /**
> @@ -558,6 +566,9 @@ enum rte_eth_fdir_status {
> RTE_ETH_FDIR_REPORT_FLEX_8,/**< Report 8 flex bytes. */
> };
>
> +/**< Max # of behavior arguments */
> +#define RTE_ETH_BEHAVIOR_ARG_MAX_LEN 256
> +
> /**
> * A structure used to define an action when match FDIR packet filter.
> */
> @@ -569,6 +580,8 @@ struct rte_eth_fdir_action {
> /**< If report_status is RTE_ETH_FDIR_REPORT_ID_FLEX_4 or
>RTE_ETH_FDIR_REPORT_FLEX_8, flex_off specifies where the
> reported
>flex bytes start from in flexible payload. */
> + uint8_t behavior_arg[RTE_ETH_BEHAVIOR_ARG_MAX_LEN];
> + /**< Extra arguments for behavior taken */
> };
>
> /**
> --
> 2.5.3
[dpdk-dev] [PATCH RFC 4/4] doc: add note about rte_vhost_enqueue_burst thread safety.
On 2/24/2016 1:07 PM, Ilya Maximets wrote: > On 23.02.2016 08:56, Xie, Huawei wrote: >> On 2/22/2016 6:16 PM, Thomas Monjalon wrote: >>> 2016-02-22 02:07, Xie, Huawei: On 2/19/2016 5:05 PM, Ilya Maximets wrote: > On 19.02.2016 11:36, Xie, Huawei wrote: >> On 2/19/2016 3:10 PM, Yuanhan Liu wrote: >>> On Fri, Feb 19, 2016 at 09:32:43AM +0300, Ilya Maximets wrote: Signed-off-by: Ilya Maximets --- doc/guides/prog_guide/thread_safety_dpdk_functions.rst | 1 + 1 file changed, 1 insertion(+) diff --git a/doc/guides/prog_guide/thread_safety_dpdk_functions.rst b/doc/guides/prog_guide/thread_safety_dpdk_functions.rst index 403e5fc..13a6c89 100644 --- a/doc/guides/prog_guide/thread_safety_dpdk_functions.rst +++ b/doc/guides/prog_guide/thread_safety_dpdk_functions.rst The mempool library is based on the DPDK lockless ring library and therefore is also multi-thread safe. +rte_vhost_enqueue_burst() is also thread safe because based on lockless ring-buffer algorithm like the ring library. >>> FYI, Huawei meant to make rte_vhost_enqueue_burst() not be thread-safe, >>> to aligh with the usage of rte_eth_tx_burst(). >>> >>> --yliu >> I have a patch to remove the lockless enqueue. Unless there is strong >> reason, i prefer vhost PMD to behave like other PMDs, with no internal >> lockless algorithm. In future, for people who really need it, we could >> have dynamic/static switch to enable it. Thomas, what is your opinion on this and my patch removing lockless enqueue? >>> The thread safety behaviour is part of the API specification. >>> If we want to enable/disable such behaviour, it must be done with an API >>> function. But it would introduce a conditional statement in the fast path. >>> That's why the priority must be to keep a simple and consistent behaviour >>> and try to build around. An API complexity may be considered only if there >>> is a real (measured) gain. >> Let us put the gain aside temporarily. I would do the measurement. >> Vhost is wrapped as a PMD in Tetsuya's patch. And also in DPDK OVS's >> case, it is wrapped as a vport like all other physical ports. The DPDK >> app/OVS will treat all ports equally. > That is not true. Currently vhost in Open vSwitch implemented as a separate > netdev class. So, to use concurrency of vhost we just need to remove > 2 lines (rte_spinlock_lock and rte_spinlock_unlock) from function > __netdev_dpdk_vhost_send(). This will not change behaviour of other types > of ports. I checked OVS implementation. It raised several concerns. For physical ports, it uses multiple queues to solve concurrent tx. For vhost ports, a) The thread safe behavior of vhost isn't used. rte_spinlock is used outside. Yes, it could be removed. b) If a packet is send to vhost, it is directly enqueued to guest without buffering. We could use thread safe ring to queue packets first and then enqueued to guest at appropriate time later, then vhost internal lockless isn't needed. Besides, IMO thread safe implementation adds the complexity of vhost implementation. >> It will add complexity if the app >> needs to know that some supports concurrency while some not. Since all >> other PMDs doesn't support thread safety, it doesn't make sense for >> vhost PMD to support that. I believe the APP will not use that behavior. >> >From the API's point of view, if we previously implemented it wrongly, >> we need to fix it as early as possible.
[dpdk-dev] [PATCH 0/2 v3] i40e: Add floating VEB support for i40e
This patch-set add the support for floating VEB in i40e. All the VFs VSIs can decide whether to connect to the legacy VEB/VEPA or the floating VEB. When connect to the floating VEB a new floating VEB is created. Now all the VFs need to connect to floating VEB or legacy VEB, cannot connect to both of them. The PF and VMDQ,FD VSIs connect to the old legacy VEB/VEPA. All the VEB/VEPA concepts are not specific for FVL, they are defined in the 802.1Qbg spec. Zhe Tao (2): support floating VEB config Add floating VEB support in i40e doc/guides/rel_notes/release_16_04.rst | 2 + doc/guides/testpmd_app_ug/run_app.rst | 4 ++ drivers/net/i40e/Makefile | 2 +- drivers/net/i40e/i40e_ethdev.c | 105 - drivers/net/i40e/i40e_ethdev.h | 4 ++ drivers/net/i40e/i40e_pf.c | 11 ++- lib/librte_eal/common/eal_common_options.c | 4 ++ lib/librte_eal/common/eal_internal_cfg.h | 1 + lib/librte_eal/common/eal_options.h| 2 + 9 files changed, 114 insertions(+), 21 deletions(-) V2: Added the release notes and changed commit log. V3: Changed the VSI release operation. -- 2.1.4
[dpdk-dev] [PATCH 1/2 v3] i40e: support floating VEB config
Add the new floating related argument option in the EAL.
Using this parameter, all the samples can decide whether to use legacy VEB/VEPA,
or floating VEB.
Even the floating argument is provided in the EAL, but this floating
feature are only support for FVL so far.
Signed-off-by: Zhe Tao
---
doc/guides/testpmd_app_ug/run_app.rst | 4
lib/librte_eal/common/eal_common_options.c | 4
lib/librte_eal/common/eal_internal_cfg.h | 1 +
lib/librte_eal/common/eal_options.h| 2 ++
4 files changed, 11 insertions(+)
diff --git a/doc/guides/testpmd_app_ug/run_app.rst
b/doc/guides/testpmd_app_ug/run_app.rst
index f605564..2f02f63 100644
--- a/doc/guides/testpmd_app_ug/run_app.rst
+++ b/doc/guides/testpmd_app_ug/run_app.rst
@@ -156,6 +156,10 @@ See the DPDK Getting Started Guides for more information
on these options.
Use malloc instead of hugetlbfs.
+* ``--floating``
+
+Enable floating feature for virtual ethernet switch in the NIC.
+Now only Intel i40e NIC supports this feature.
Testpmd Command-line Options
diff --git a/lib/librte_eal/common/eal_common_options.c
b/lib/librte_eal/common/eal_common_options.c
index 29942ea..29ed7bf 100644
--- a/lib/librte_eal/common/eal_common_options.c
+++ b/lib/librte_eal/common/eal_common_options.c
@@ -95,6 +95,7 @@ eal_long_options[] = {
{OPT_VFIO_INTR, 1, NULL, OPT_VFIO_INTR_NUM},
{OPT_VMWARE_TSC_MAP,0, NULL, OPT_VMWARE_TSC_MAP_NUM },
{OPT_XEN_DOM0, 0, NULL, OPT_XEN_DOM0_NUM },
+ {OPT_FLOATING, 0, NULL, OPT_FLOATING_NUM },
{0, 0, NULL, 0}
};
@@ -896,6 +897,9 @@ eal_parse_common_option(int opt, const char *optarg,
return -1;
}
break;
+ case OPT_FLOATING_NUM:
+ conf->floating = 1;
+ break;
/* don't know what to do, leave this to caller */
default:
diff --git a/lib/librte_eal/common/eal_internal_cfg.h
b/lib/librte_eal/common/eal_internal_cfg.h
index 5f1367e..19b321a 100644
--- a/lib/librte_eal/common/eal_internal_cfg.h
+++ b/lib/librte_eal/common/eal_internal_cfg.h
@@ -68,6 +68,7 @@ struct internal_config {
volatile unsigned xen_dom0_support; /**< support app running on Xen
Dom0*/
volatile unsigned no_pci; /**< true to disable PCI */
volatile unsigned no_hpet;/**< true to disable HPET */
+ volatile unsigned floating; /**< true to enable floating VEB */
volatile unsigned vmware_tsc_map; /**< true to use VMware TSC mapping
* instead of native TSC */
volatile unsigned no_shconf; /**< true if there is no shared
config */
diff --git a/lib/librte_eal/common/eal_options.h
b/lib/librte_eal/common/eal_options.h
index a881c62..413c9e6 100644
--- a/lib/librte_eal/common/eal_options.h
+++ b/lib/librte_eal/common/eal_options.h
@@ -83,6 +83,8 @@ enum {
OPT_VMWARE_TSC_MAP_NUM,
#define OPT_XEN_DOM0 "xen-dom0"
OPT_XEN_DOM0_NUM,
+#define OPT_FLOATING "floating"
+ OPT_FLOATING_NUM,
OPT_LONG_MAX_NUM
};
--
2.1.4
[dpdk-dev] [PATCH 2/2 v3] i40e: Add floating VEB support in i40e
This patch add the support for floating VEB in i40e.
All the VFs VSIs can decide whether to connect to the legacy VEB/VEPA or
the floating VEB. When connect to the floating VEB a new floating VEB is
created. Now all the VFs need to connect to floating VEB or legacy VEB,
cannot connect to both of them. The PF and VMDQ,FD VSIs still connect to
the old legacy VEB/VEPA.
All the VEB/VEPA concepts are not specific for FVL, they are defined in the
802.1Qbg spec.
Signed-off-by: Zhe Tao
---
doc/guides/rel_notes/release_16_04.rst | 2 +
drivers/net/i40e/Makefile | 2 +-
drivers/net/i40e/i40e_ethdev.c | 105 +++--
drivers/net/i40e/i40e_ethdev.h | 4 ++
drivers/net/i40e/i40e_pf.c | 11 +++-
5 files changed, 103 insertions(+), 21 deletions(-)
diff --git a/doc/guides/rel_notes/release_16_04.rst
b/doc/guides/rel_notes/release_16_04.rst
index 5786f74..446112c 100644
--- a/doc/guides/rel_notes/release_16_04.rst
+++ b/doc/guides/rel_notes/release_16_04.rst
@@ -46,6 +46,8 @@ This section should contain new features added in this
release. Sample format:
* **Added vhost-user live migration support.**
+* **Added floating VEB support for FVL.**
+
Resolved Issues
---
diff --git a/drivers/net/i40e/Makefile b/drivers/net/i40e/Makefile
index 033ee4a..2e01d45 100644
--- a/drivers/net/i40e/Makefile
+++ b/drivers/net/i40e/Makefile
@@ -39,7 +39,7 @@ LIB = librte_pmd_i40e.a
CFLAGS += -O3
CFLAGS += $(WERROR_FLAGS) -DPF_DRIVER -DVF_DRIVER -DINTEGRATED_VF
CFLAGS += -DX722_SUPPORT -DX722_A0_SUPPORT
-
+CFLAGS += -I$(RTE_SDK)/lib/librte_eal/common
EXPORT_MAP := rte_pmd_i40e_version.map
LIBABIVER := 1
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index ef24122..f8554c9 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -744,6 +744,7 @@ eth_i40e_dev_init(struct rte_eth_dev *dev)
pf->adapter = I40E_DEV_PRIVATE_TO_ADAPTER(dev->data->dev_private);
pf->adapter->eth_dev = dev;
pf->dev_data = dev->data;
+ pf->floating = internal_config.floating;
hw->back = I40E_PF_TO_ADAPTER(pf);
hw->hw_addr = (uint8_t *)(pci_dev->mem_resource[0].addr);
@@ -3592,21 +3593,27 @@ i40e_veb_release(struct i40e_veb *veb)
struct i40e_vsi *vsi;
struct i40e_hw *hw;
- if (veb == NULL || veb->associate_vsi == NULL)
+ if (veb == NULL)
return -EINVAL;
if (!TAILQ_EMPTY(&veb->head)) {
PMD_DRV_LOG(ERR, "VEB still has VSI attached, can't remove");
return -EACCES;
}
+ /* associate_vsi field is NULL for floating VEB */
+ if (veb->associate_vsi != NULL) {
+ vsi = veb->associate_vsi;
+ hw = I40E_VSI_TO_HW(vsi);
- vsi = veb->associate_vsi;
- hw = I40E_VSI_TO_HW(vsi);
+ vsi->uplink_seid = veb->uplink_seid;
+ vsi->veb = NULL;
+ } else {
+ veb->associate_pf->main_vsi->floating_veb = NULL;
+ hw = I40E_VSI_TO_HW(veb->associate_pf->main_vsi);
+ }
- vsi->uplink_seid = veb->uplink_seid;
i40e_aq_delete_element(hw, veb->seid, NULL);
rte_free(veb);
- vsi->veb = NULL;
return I40E_SUCCESS;
}
@@ -3618,9 +3625,9 @@ i40e_veb_setup(struct i40e_pf *pf, struct i40e_vsi *vsi)
int ret;
struct i40e_hw *hw;
- if (NULL == pf || vsi == NULL) {
+ if (NULL == pf) {
PMD_DRV_LOG(ERR, "veb setup failed, "
- "associated VSI shouldn't null");
+ "associated PF shouldn't null");
return NULL;
}
hw = I40E_PF_TO_HW(pf);
@@ -3632,11 +3639,19 @@ i40e_veb_setup(struct i40e_pf *pf, struct i40e_vsi *vsi)
}
veb->associate_vsi = vsi;
+ veb->associate_pf = pf;
TAILQ_INIT(&veb->head);
- veb->uplink_seid = vsi->uplink_seid;
+ veb->uplink_seid = vsi ? vsi->uplink_seid : 0;
- ret = i40e_aq_add_veb(hw, veb->uplink_seid, vsi->seid,
- I40E_DEFAULT_TCMAP, false, false, &veb->seid, NULL);
+ /* create floating veb if vsi is NULL */
+ if (vsi != NULL) {
+ ret = i40e_aq_add_veb(hw, veb->uplink_seid, vsi->seid,
+ I40E_DEFAULT_TCMAP, false, false,
+ &veb->seid, NULL);
+ } else {
+ ret = i40e_aq_add_veb(hw, 0, 0, I40E_DEFAULT_TCMAP,
+ false, false, &veb->seid, NULL);
+ }
if (ret != I40E_SUCCESS) {
PMD_DRV_LOG(ERR, "Add veb failed, aq_err: %d",
@@ -3688,12 +3703,22 @@ i40e_vsi_release(struct i40e_vsi *vsi)
i40e_veb_release(vsi->veb);
}
+ if (vsi->floating_veb) {
+ TAILQ_FOREACH(vsi_list, &vsi->floating_veb->head, list) {
+ if (i40e_vsi_release(vsi
[dpdk-dev] [PATCH v2 07/12] pmd/ixgbe: add dev_ptype_info_get implementation
Hi Konstantin,
On 1/15/2016 10:50 PM, Ananyev, Konstantin wrote:
>
>> -Original Message-
>> From: Tan, Jianfeng
>> Sent: Friday, January 15, 2016 5:46 AM
>> To: dev at dpdk.org
>> Cc: Zhang, Helin; Ananyev, Konstantin; Tan, Jianfeng
>> Subject: [PATCH v2 07/12] pmd/ixgbe: add dev_ptype_info_get implementation
>>
>> Signed-off-by: Jianfeng Tan
>> ---
>> drivers/net/ixgbe/ixgbe_ethdev.c | 38
>> ++
>> drivers/net/ixgbe/ixgbe_ethdev.h | 2 ++
>> drivers/net/ixgbe/ixgbe_rxtx.c | 5 -
>> 3 files changed, 44 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
>> b/drivers/net/ixgbe/ixgbe_ethdev.c
>> index 4c4c6df..b3ae7b2 100644
>> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
>> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
>> @@ -166,6 +166,7 @@ static int ixgbe_dev_queue_stats_mapping_set(struct
>> rte_eth_dev *eth_dev,
>> uint8_t is_rx);
>> static void ixgbe_dev_info_get(struct rte_eth_dev *dev,
>> struct rte_eth_dev_info *dev_info);
>> +static int ixgbe_dev_ptype_info_get(struct rte_eth_dev *dev, uint32_t
>> ptypes[]);
>> static void ixgbevf_dev_info_get(struct rte_eth_dev *dev,
>> struct rte_eth_dev_info *dev_info);
>> static int ixgbe_dev_mtu_set(struct rte_eth_dev *dev, uint16_t mtu);
>> @@ -428,6 +429,7 @@ static const struct eth_dev_ops ixgbe_eth_dev_ops = {
>> .xstats_reset = ixgbe_dev_xstats_reset,
>> .queue_stats_mapping_set = ixgbe_dev_queue_stats_mapping_set,
>> .dev_infos_get= ixgbe_dev_info_get,
>> +.dev_ptype_info_get = ixgbe_dev_ptype_info_get,
>> .mtu_set = ixgbe_dev_mtu_set,
>> .vlan_filter_set = ixgbe_vlan_filter_set,
>> .vlan_tpid_set= ixgbe_vlan_tpid_set,
>> @@ -512,6 +514,7 @@ static const struct eth_dev_ops ixgbevf_eth_dev_ops = {
>> .xstats_reset = ixgbevf_dev_stats_reset,
>> .dev_close= ixgbevf_dev_close,
>> .dev_infos_get= ixgbevf_dev_info_get,
>> +.dev_ptype_info_get = ixgbe_dev_ptype_info_get,
>> .mtu_set = ixgbevf_dev_set_mtu,
>> .vlan_filter_set = ixgbevf_vlan_filter_set,
>> .vlan_strip_queue_set = ixgbevf_vlan_strip_queue_set,
>> @@ -2829,6 +2832,41 @@ ixgbe_dev_info_get(struct rte_eth_dev *dev, struct
>> rte_eth_dev_info *dev_info)
>> dev_info->flow_type_rss_offloads = IXGBE_RSS_OFFLOAD_ALL;
>> }
>>
>> +static int
>> +ixgbe_dev_ptype_info_get(struct rte_eth_dev *dev, uint32_t ptypes[])
>> +{
>> +int num = 0;
>> +
>> +if (dev->rx_pkt_burst == ixgbe_recv_pkts ||
>> +dev->rx_pkt_burst == ixgbe_recv_pkts_lro_single_alloc ||
>> +dev->rx_pkt_burst == ixgbe_recv_pkts_lro_bulk_alloc ||
>> +dev->rx_pkt_burst == ixgbe_recv_pkts_bulk_alloc ||
>> +dev->rx_pkt_burst == ixgbe_recv_pkts_vec ||
>> +dev->rx_pkt_burst == ixgbe_recv_scattered_pkts_vec) {
> Is there any point in that big if above?
> All ixgbe recv functions support ptype recognition, so why to have it at all?
> Same question for igb.
> Konstantin
I'd like this code to put it explicitly instead of an "if
(dev->rx_pkt_burst)" to indicate that all ixgbe recv functions supports
these ptypes.
Is it make sense?
Thanks,
Jianfeng
[dpdk-dev] [PATCH v2 01/12] ethdev: add API to query packet type filling info
Hi Konstantin,
On 1/15/2016 11:03 PM, Ananyev, Konstantin wrote:
>
>> -Original Message-
>> From: Tan, Jianfeng
>> Sent: Friday, January 15, 2016 5:46 AM
>> To: dev at dpdk.org
>> Cc: Zhang, Helin; Ananyev, Konstantin; Tan, Jianfeng
>> Subject: [PATCH v2 01/12] ethdev: add API to query packet type filling info
>>
>> Add a new API rte_eth_dev_get_ptype_info to query wether/what packet type
>> will
>> be filled by given pmd rx burst function.
>>
>> Signed-off-by: Jianfeng Tan
>> ---
>> lib/librte_ether/rte_ethdev.c | 20
>> lib/librte_ether/rte_ethdev.h | 27 +++
>> lib/librte_mbuf/rte_mbuf.h| 6 ++
>> 3 files changed, 53 insertions(+)
>>
>> diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
>> index ed971b4..cd34f46 100644
>> --- a/lib/librte_ether/rte_ethdev.c
>> +++ b/lib/librte_ether/rte_ethdev.c
>> @@ -1614,6 +1614,26 @@ rte_eth_dev_info_get(uint8_t port_id, struct
>> rte_eth_dev_info *dev_info)
>> dev_info->driver_name = dev->data->drv_name;
>> }
>>
>> +int
>> +rte_eth_dev_get_ptype_info(uint8_t port_id, uint32_t ptype_mask,
>> + uint32_t ptypes[], int num)
>> +{
>> +int ret, i, j;
>> +struct rte_eth_dev *dev;
>> +uint32_t all_ptypes[RTE_PTYPE_MAX_NUM];
>> +
>> +RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
>> +dev = &rte_eth_devices[port_id];
>> +RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_ptype_info_get, -ENOTSUP);
>> +ret = (*dev->dev_ops->dev_ptype_info_get)(dev, all_ptypes);
>> +
>> +for (i = 0, j = 0; i < ret && j < num; ++i)
>> +if (all_ptypes[i] & ptype_mask)
>> +ptypes[j++] = all_ptypes[i];
>> +
>> +return ret;
> I think it needs to be something like:
>
> j = 0;
> for (i = 0, j = 0; i < ret; ++i) {
> if (all_ptypes[i] & ptype_mask) {
>if (j < num)
> ptypes[j] = all_ptypes[i];
>j++;
> }
> }
>
> return j;
>
> Konstantin
>
You are right, my previous code is wrong.
But I have a concern about your code above: under the condition that the
caller does not provide big enough array to store adequate ptypes, it
has no way to return the not-enough-memory message back to caller.
So under that condition, how about we just return -ENOMEM?
Thanks,
Jianfeng
[dpdk-dev] [PATCH v2 1/3] i40e: enable DCB in VMDQ VSIs
> > + /* 4 bits per TC, 4th bit is reserved */
> > + veb->bw_info.bw_ets_max[i] =
> > + (uint8_t)((bw_max >> (i * I40E_4_BIT_WIDTH)) &
> > + I40E_3_BIT_MASK);
> Use RTE_LEN2MASK() to replace I40E_3_BIT_MASK.
OK.
>
> > + PMD_DRV_LOG(DEBUG, "\tVEB TC%u:share credits %u", i,
> > + veb->bw_info.bw_ets_share_credits[i]);
> > + PMD_DRV_LOG(DEBUG, "\tVEB TC%u:credits %u", i,
> > + veb->bw_info.bw_ets_credits[i]);
> > + PMD_DRV_LOG(DEBUG, "\tVEB TC%u: max credits: %u", i,
> > + veb->bw_info.bw_ets_max[i]);
> > + }
> > +
> > + veb->enabled_tc = tc_map;
> > +
> > + return ret;
> > +}
> > +
> > +
> > +/*
> > * i40e_vsi_config_tc - Configure VSI tc setting for given TC map
> > * @vsi: VSI to be configured
> > * @tc_map: enabled TC bitmap
> > @@ -8152,7 +8252,7 @@ i40e_vsi_update_queue_mapping(struct i40e_vsi
> > *vsi,
> > * Returns 0 on success, negative value on failure
> > */
> > static enum i40e_status_code
> > -i40e_vsi_config_tc(struct i40e_vsi *vsi, u8 tc_map)
> > +i40e_vsi_config_tc(struct i40e_vsi *vsi, uint8_t tc_map)
> > {
> > struct i40e_aqc_configure_vsi_tc_bw_data bw_data;
> > struct i40e_vsi_context ctxt;
> > @@ -8294,15 +8394,27 @@ i40e_dcb_hw_configure(struct i40e_pf *pf,
> > i40e_aq_get_dcb_config(hw, I40E_AQ_LLDP_MIB_LOCAL, 0,
> > &hw->local_dcbx_config);
> >
> > + /* if Veb is created, need to update TC of it at first */
> > + if (main_vsi->veb) {
> > + ret = i40e_config_switch_comp_tc(main_vsi->veb, tc_map);
> > + if (ret)
> > + PMD_INIT_LOG(WARNING,
> > +"Failed configuring TC for VEB seid=%d\n",
> > +main_vsi->veb->seid);
> > + }
> How about if VEB hasn't been created?
If VEB is not created, no need to update tc on switch comp.
Thanks
Jingjing
>
> > 2.4.0
[dpdk-dev] [PATCH v3 0/3] extend vmdq_dcb sample for X710 supporting
Currently, the example vmdq_dcb only works on Intel(R) 82599 NICs. This patchset extended this sample to make it works both on Intel(R) 82599 and X710/XL710 NICs. This patch set also enabled DCB VMDQ mode in i40e driver and added unsupported mode checking in ixgbe driver. v2 changes: - commit log doc rewording. - rebase on latest dpdk-next-net/rel_16_04 branch. - code style fix v3 changes: - replace I40E_3_BIT_MASK with RTE_LEN2MASK() Jingjing Wu (3): i40e: enable DCB in VMDQ VSIs ixgbe: disallow unsupported RX mode examples/vmdq_dcb: extend sample for X710 supporting doc/guides/rel_notes/release_16_04.rst | 3 + doc/guides/sample_app_ug/vmdq_dcb_forwarding.rst | 171 ++ drivers/net/i40e/i40e_ethdev.c | 156 +++-- drivers/net/i40e/i40e_ethdev.h | 28 +- drivers/net/ixgbe/ixgbe_ethdev.c | 5 + examples/vmdq_dcb/main.c | 391 ++- 6 files changed, 589 insertions(+), 165 deletions(-) -- 2.4.0
[dpdk-dev] [PATCH v3 1/3] i40e: enable DCB in VMDQ VSIs
Previously, DCB(Data Center Bridging) is only enabled on PF,
queue mapping and BW configuration is only done on PF.
This patch enabled DCB for VMDQ VSIs(Virtual Station Interfaces)
by following steps:
1. Take BW and ETS(Enhanced Transmission Selection)
configuration on VEB(Virtual Ethernet Bridge).
2. Take BW and ETS configuration on VMDQ VSIs.
3. Update TC(Traffic Class) and queues mapping on VMDQ VSIs.
To enable DCB on VMDQ, the number of TCs should not be lager than
the number of queues in VMDQ pools, and the number of queues per
VMDQ pool is specified by CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_VM
in config/common_* file.
Signed-off-by: Jingjing Wu
---
doc/guides/rel_notes/release_16_04.rst | 3 +
drivers/net/i40e/i40e_ethdev.c | 156 -
drivers/net/i40e/i40e_ethdev.h | 28 +++---
3 files changed, 153 insertions(+), 34 deletions(-)
diff --git a/doc/guides/rel_notes/release_16_04.rst
b/doc/guides/rel_notes/release_16_04.rst
index 81f62f1..d3b035c 100644
--- a/doc/guides/rel_notes/release_16_04.rst
+++ b/doc/guides/rel_notes/release_16_04.rst
@@ -56,6 +56,9 @@ This section should contain new features added in this
release. Sample format:
Added support for sw-firmware sync for resource sharing.
Use the PHY token, shared between sw-fw for PHY access on X550EM_a.
+* **VMDQ DCB mode in i40e.**
+
+ Added support for DCB in VMDQ mode to i40e driver.
Resolved Issues
---
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index ef24122..8831074 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -3760,7 +3760,6 @@ i40e_update_default_filter_setting(struct i40e_vsi *vsi)
return i40e_vsi_add_mac(vsi, &filter);
}
-#define I40E_3_BIT_MASK 0x7
/*
* i40e_vsi_get_bw_config - Query VSI BW Information
* @vsi: the VSI to be queried
@@ -3810,7 +3809,7 @@ i40e_vsi_get_bw_config(struct i40e_vsi *vsi)
/* 4 bits per TC, 4th bit is reserved */
vsi->bw_info.bw_ets_max[i] =
(uint8_t)((bw_max >> (i * I40E_4_BIT_WIDTH)) &
- I40E_3_BIT_MASK);
+ RTE_LEN2MASK(3, uint8_t));
PMD_DRV_LOG(DEBUG, "\tVSI TC%u:share credits %u", i,
vsi->bw_info.bw_ets_share_credits[i]);
PMD_DRV_LOG(DEBUG, "\tVSI TC%u:credits %u", i,
@@ -8087,6 +8086,8 @@ i40e_vsi_update_queue_mapping(struct i40e_vsi *vsi,
int i, total_tc = 0;
uint16_t qpnum_per_tc, bsf, qp_idx;
struct rte_eth_dev_data *dev_data = I40E_VSI_TO_DEV_DATA(vsi);
+ struct i40e_pf *pf = I40E_VSI_TO_PF(vsi);
+ uint16_t used_queues;
ret = validate_tcmap_parameter(vsi, enabled_tcmap);
if (ret != I40E_SUCCESS)
@@ -8100,7 +8101,18 @@ i40e_vsi_update_queue_mapping(struct i40e_vsi *vsi,
total_tc = 1;
vsi->enabled_tc = enabled_tcmap;
- qpnum_per_tc = dev_data->nb_rx_queues / total_tc;
+ /* different VSI has different queues assigned */
+ if (vsi->type == I40E_VSI_MAIN)
+ used_queues = dev_data->nb_rx_queues -
+ pf->nb_cfg_vmdq_vsi * RTE_LIBRTE_I40E_QUEUE_NUM_PER_VM;
+ else if (vsi->type == I40E_VSI_VMDQ2)
+ used_queues = RTE_LIBRTE_I40E_QUEUE_NUM_PER_VM;
+ else {
+ PMD_INIT_LOG(ERR, "unsupported VSI type.");
+ return I40E_ERR_NO_AVAILABLE_VSI;
+ }
+
+ qpnum_per_tc = used_queues / total_tc;
/* Number of queues per enabled TC */
if (qpnum_per_tc == 0) {
PMD_INIT_LOG(ERR, " number of queues is less that tcs.");
@@ -8145,6 +8157,93 @@ i40e_vsi_update_queue_mapping(struct i40e_vsi *vsi,
}
/*
+ * i40e_config_switch_comp_tc - Configure VEB tc setting for given TC map
+ * @veb: VEB to be configured
+ * @tc_map: enabled TC bitmap
+ *
+ * Returns 0 on success, negative value on failure
+ */
+static enum i40e_status_code
+i40e_config_switch_comp_tc(struct i40e_veb *veb, uint8_t tc_map)
+{
+ struct i40e_aqc_configure_switching_comp_bw_config_data veb_bw;
+ struct i40e_aqc_query_switching_comp_bw_config_resp bw_query;
+ struct i40e_aqc_query_switching_comp_ets_config_resp ets_query;
+ struct i40e_hw *hw = I40E_VSI_TO_HW(veb->associate_vsi);
+ enum i40e_status_code ret = I40E_SUCCESS;
+ int i;
+ uint32_t bw_max;
+
+ /* Check if enabled_tc is same as existing or new TCs */
+ if (veb->enabled_tc == tc_map)
+ return ret;
+
+ /* configure tc bandwidth */
+ memset(&veb_bw, 0, sizeof(veb_bw));
+ veb_bw.tc_valid_bits = tc_map;
+ /* Enable ETS TCs with equal BW Share for now across all VSIs */
+ for (i = 0; i < I40E_MAX_TRAFFIC_CLASS; i++) {
+ if (tc_map & BIT_ULL(i))
+ veb_bw.tc_bw_share_credits[i] = 1;
+ }
+ ret = i40e_
[dpdk-dev] [PATCH v3 2/3] ixgbe: disallow unsupported RX mode
The multi queue mode ETH_MQ_RX_VMDQ_DCB_RSS is not supported in
ixgbe driver. This patch added the checking.
Signed-off-by: Jingjing Wu
---
drivers/net/ixgbe/ixgbe_ethdev.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index a1596b3..ce32cbc 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -1855,6 +1855,11 @@ ixgbe_check_mq_mode(struct rte_eth_dev *dev)
return -EINVAL;
}
} else {
+ if (dev_conf->rxmode.mq_mode == ETH_MQ_RX_VMDQ_DCB_RSS) {
+ PMD_INIT_LOG(ERR, "VMDQ+DCB+RSS mq_mode is"
+ " not supported.");
+ return -EINVAL;
+ }
/* check configuration for vmdb+dcb mode */
if (dev_conf->rxmode.mq_mode == ETH_MQ_RX_VMDQ_DCB) {
const struct rte_eth_vmdq_dcb_conf *conf;
--
2.4.0
[dpdk-dev] [PATCH v3 3/3] examples/vmdq_dcb: extend sample for X710 supporting
Currently, the example vmdq_dcb only works on Intel(R) 82599 NICs. This patch extended this sample to make it work both on Intel(R) 82599 and X710/XL710 NICs by following changes: 1. add VMDQ base queue checking to avoid forwarding on PF queues. 2. assign each VMDQ pools with MAC address. 3. add more arguments (nb-tcs, enable-rss) to change the default setting 4. extend the max number of queues from 128 to 1024. This patch also reworked the user guide for the vmdq_dcb sample. Signed-off-by: Jingjing Wu --- doc/guides/sample_app_ug/vmdq_dcb_forwarding.rst | 171 ++ examples/vmdq_dcb/main.c | 391 ++- 2 files changed, 431 insertions(+), 131 deletions(-) diff --git a/doc/guides/sample_app_ug/vmdq_dcb_forwarding.rst b/doc/guides/sample_app_ug/vmdq_dcb_forwarding.rst index 9140a22..305636b 100644 --- a/doc/guides/sample_app_ug/vmdq_dcb_forwarding.rst +++ b/doc/guides/sample_app_ug/vmdq_dcb_forwarding.rst @@ -32,8 +32,8 @@ VMDQ and DCB Forwarding Sample Application == The VMDQ and DCB Forwarding sample application is a simple example of packet processing using the DPDK. -The application performs L2 forwarding using VMDQ and DCB to divide the incoming traffic into 128 queues. -The traffic splitting is performed in hardware by the VMDQ and DCB features of the Intel? 82599 10 Gigabit Ethernet Controller. +The application performs L2 forwarding using VMDQ and DCB to divide the incoming traffic into queues. +The traffic splitting is performed in hardware by the VMDQ and DCB features of the Intel? 82599 and X710/XL710 Ethernet Controllers. Overview @@ -41,28 +41,27 @@ Overview This sample application can be used as a starting point for developing a new application that is based on the DPDK and uses VMDQ and DCB for traffic partitioning. -The VMDQ and DCB filters work on VLAN traffic to divide the traffic into 128 input queues on the basis of the VLAN ID field and -VLAN user priority field. -VMDQ filters split the traffic into 16 or 32 groups based on the VLAN ID. -Then, DCB places each packet into one of either 4 or 8 queues within that group, based upon the VLAN user priority field. - -In either case, 16 groups of 8 queues, or 32 groups of 4 queues, the traffic can be split into 128 hardware queues on the NIC, -each of which can be polled individually by a DPDK application. +The VMDQ and DCB filters work on MAC and VLAN traffic to divide the traffic into input queues on the basis of the Destination MAC +address, VLAN ID and VLAN user priority fields. +VMDQ filters split the traffic into 16 or 32 groups based on the Destination MAC and VLAN ID. +Then, DCB places each packet into one of queues within that group, based upon the VLAN user priority field. All traffic is read from a single incoming port (port 0) and output on port 1, without any processing being performed. -The traffic is split into 128 queues on input, where each thread of the application reads from multiple queues. -For example, when run with 8 threads, that is, with the -c FF option, each thread receives and forwards packets from 16 queues. +With Intel? 82599 NIC, for example, the traffic is split into 128 queues on input, where each thread of the application reads from +multiple queues. When run with 8 threads, that is, with the -c FF option, each thread receives and forwards packets from 16 queues. -As supplied, the sample application configures the VMDQ feature to have 16 pools with 8 queues each as indicated in :numref:`figure_vmdq_dcb_example`. -The Intel? 82599 10 Gigabit Ethernet Controller NIC also supports the splitting of traffic into 32 pools of 4 queues each and -this can be used by changing the NUM_POOLS parameter in the supplied code. -The NUM_POOLS parameter can be passed on the command line, after the EAL parameters: +As supplied, the sample application configures the VMDQ feature to have 32 pools with 4 queues each as indicated in :numref:`figure_vmdq_dcb_example`. +The Intel? 82599 10 Gigabit Ethernet Controller NIC also supports the splitting of traffic into 16 pools of 8 queues. While the +Intel? X710 or XL710 Ethernet Controller NICs support many configurations of VMDQ pools of 4 or 8 queues each. For simplicity, only 16 +or 32 pools is supported in this sample. And queues numbers for each VMDQ pool can be changed by setting CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_VM +in config/common_* file. +The nb-pools, nb-tcs and enable-rss parameters can be passed on the command line, after the EAL parameters: .. code-block:: console -./build/vmdq_dcb [EAL options] -- -p PORTMASK --nb-pools NP +./build/vmdq_dcb [EAL options] -- -p PORTMASK --nb-pools NP --nb-tcs TC --enable-rss -where, NP can be 16 or 32. +where, NP can be 16 or 32, TC can be 4 or 8, rss is disabled by default. .. _figure_vmdq_dcb_example: @@ -72,9 +71,7 @@ where, NP can be 16 or 32. In Linux* user space, th
[dpdk-dev] [PATCH 00/12] extend flow director's fields in i40e driver
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce Richardson > Sent: Wednesday, February 24, 2016 7:45 PM > To: Wu, Jingjing > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH 00/12] extend flow director's fields in i40e > driver > > On Tue, Jan 26, 2016 at 02:26:03PM +0800, Jingjing Wu wrote: > > This patch set extends flow director to support filtering by > > additional fields below in i40e driver: > > - TOS, Protocol and TTL in IP header > > - Tunnel id if NVGRE/GRE/VxLAN packets > > - single vlan or inner vlan > > > > Jingjing Wu (12): > > ethdev: extend flow director to support input set selection > > i40e: split function for input set change of hash and fdir > > i40e: remove flex payload from INPUT_SET_SELECT operation > > i40e: restore default setting on input set of filters > > i40e: extend flow director to filter by more IP Header fields > > testpmd: extend commands for filter's input set changing > > librte_ether: extend rte_eth_fdir_flow to support tunnel format > > i40e: extend flow director to filter by tunnel ID > > testpmd: extend commands for fdir's tunnel id input set > > i40e: fix VLAN bitmasks for hash/fdir input sets for tunnels > > i40e: extend flow director to filter by vlan id > > testpmd: extend commands for fdir's vlan input set > > > > app/test-pmd/cmdline.c | 121 +++-- > > doc/guides/rel_notes/release_2_3.rst| 5 + > > doc/guides/testpmd_app_ug/testpmd_funcs.rst | 56 ++-- > > drivers/net/i40e/i40e_ethdev.c | 401 > > +-- > - > > drivers/net/i40e/i40e_ethdev.h | 11 +- > > drivers/net/i40e/i40e_fdir.c| 163 --- > > lib/librte_ether/rte_eth_ctrl.h | 35 ++- > > 7 files changed, 529 insertions(+), 263 deletions(-) > > > > -- > > 2.4.0 > > > > Any review or comments on this patchset? I am now reviewing it, hopefully review comments will be sent out in the following days. Thanks, Helin > > /Bruce
[dpdk-dev] [PATCH v9 0/2] Add VHOST PMD
On 2/24/2016 1:10 PM, Tetsuya Mukawa wrote: > On 2016/02/24 11:45, Qiu, Michael wrote: >> Hi, Tetsuya >> >> When I applied your v6 patch, I could reach 9.5Mpps with 64B packet. >> >> But when apply v9 only 8.4 Mpps, could you figure out why has >> performance drop? > Hi Michael, > > Thanks for checking it. > I tried to re-produce it, but I don't see the drop on my environment. > (My cpu is Xeon E5-2697-v2, and the performances of v6 and v9 patch are > almost 5.9Mpps) > Did you use totally same code except for vhost PMD? Yes, totally same code and same platform, only difference is versions of vhost PMD. BTW, I have set the frontend mergeable off. Thanks, Michael > > Thanks, > Tetsuya > >> Thanks, >> Michael >> On 2/9/2016 5:38 PM, Tetsuya Mukawa wrote: >>> The patch introduces a new PMD. This PMD is implemented as thin wrapper >>> of librte_vhost. >>> >>> >>> PATCH v9 changes: >>> - Fix a null pointer access issue implemented in v8 patch. >>> >>> PATCH v8 changes: >>> - Manage ether devices list instead of internal structures list. >>> - Remove needless NULL checking. >>> - Replace "pthread_exit" to "return NULL". >>> - Replace rte_panic to RTE_LOG, also add error handling. >>> - Remove duplicated lines. >>> - Remove needless casting. >>> - Follow coding style. >>> - Remove needless parenthesis. >>> >>> 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 >>> >>> MAINTAINERS | 4 + >>> config/common_linuxapp | 6 + >>> doc/guides/nics/index.rst | 1 + >>> doc/guides/rel_notes/release_2_3.rst| 4 + >>> drivers/net/Makefile| 4 + >>> drivers/net/vhost/Makefile | 62 ++ >>> drivers/net/vhost/rte_eth_vhost.c | 911 >>> >>> drivers/net/vhost/rte_eth_vhost.h | 109 >>> drivers/net/vhost/rte_pmd_vhost_version.map | 11 + >>> lib/librte_ether/rte_ethdev.h
[dpdk-dev] [PATCH] vhost: broadcast RARP pkt by injecting it to receiving mbuf array
On 2/24/2016 4:27 PM, Yuanhan Liu wrote:
> On Wed, Feb 24, 2016 at 08:15:36AM +, Qiu, Michael wrote:
>> On 2/22/2016 10:35 PM, Yuanhan Liu wrote:
>>> Broadcast RARP packet by injecting it to receiving mbuf array at
>>> rte_vhost_dequeue_burst().
>>>
>>> Commit 33226236a35e ("vhost: handle request to send RARP") iterates
>>> all host interfaces and then broadcast it by all of them. It did
>>> notify the switches about the new location of the migrated VM, however,
>>> the mac learning table in the target host is wrong (at least in my
>>> test with OVS):
>>>
>>> $ ovs-appctl fdb/show ovsbr0
>>> port VLAN MACAge
>>> 1 0 b6:3c:72:71:cd:4d 10
>>> LOCAL 0 b6:3c:72:71:cd:4e 10
>>> LOCAL 0 52:54:00:12:34:689
>>> 1 0 56:f6:64:2c:bc:c01
>>>
>>> Where 52:54:00:12:34:68 is the mac of the VM. As you can see from the
>>> above, the port learned is "LOCAL", which is the "ovsbr0" port. That
>>> is reasonable, since we indeed send the pkt by the "ovsbr0" interface.
>>>
>>> The wrong mac table lead all the packets to the VM go to the "ovsbr0"
>>> in the end, which ends up with all packets being lost, until the guest
>>> send a ARP quest (or reply) to refresh the mac learning table.
>>>
>>> Jianfeng then came up with a solution I have thought of firstly but NAKed
>> Is it suitable to mention someone in the commit log?
> Why it's not? It's not a secret name or something like that after all :)
>
> On the other hand, it's way of thanking Jianfeng's contribution to this
> patch.
OK, I've never seen this fashion before, forgive me.
Thanks,
Michael
>
> --yliu
>
[dpdk-dev] [PATCH 02/12] i40e: split function for input set change of hash and fdir
Jingjing
Your patches have depencies on my i40e base driver udpate patch set.
Some registers should be read/written by AQ commands, with using interfaces
of i40e_read_rx_ctl() and i40e_write_rx_ctl().
Please check below link and see the list of those registers.
http://www.dpdk.org/dev/patchwork/patch/10654/
Regards,
Helin
> -Original Message-
> From: Wu, Jingjing
> Sent: Tuesday, January 26, 2016 2:26 PM
> To: dev at dpdk.org
> Cc: Wu, Jingjing; Zhang, Helin; Chilikin, Andrey; Lu, Wenzhuo; Pei, Yulong
> Subject: [PATCH 02/12] i40e: split function for input set change of hash and
> fdir
>
> This patch split function for input set changing of hash and fdir to avoid
> multiple check on different situation.
>
> Signed-off-by: Jingjing Wu
> ---
> drivers/net/i40e/i40e_ethdev.c | 233 +
>
> drivers/net/i40e/i40e_ethdev.h | 11 +-
> drivers/net/i40e/i40e_fdir.c | 5 +-
> 3 files changed, 107 insertions(+), 142 deletions(-)
>
> diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
> index bf6220d..004e206 100644
> --- a/drivers/net/i40e/i40e_ethdev.c
> +++ b/drivers/net/i40e/i40e_ethdev.c
> @@ -6845,25 +6845,6 @@ i40e_generate_inset_mask_reg(uint64_t inset,
> uint32_t *mask, uint8_t nb_elem)
> return idx;
> }
>
> -static uint64_t
> -i40e_get_reg_inset(struct i40e_hw *hw, enum rte_filter_type filter,
> - enum i40e_filter_pctype pctype)
> -{
> - uint64_t reg = 0;
> -
> - if (filter == RTE_ETH_FILTER_HASH) {
> - reg = I40E_READ_REG(hw, I40E_GLQF_HASH_INSET(1,
> pctype));
> - reg <<= I40E_32_BIT_WIDTH;
> - reg |= I40E_READ_REG(hw, I40E_GLQF_HASH_INSET(0,
> pctype));
> - } else if (filter == RTE_ETH_FILTER_FDIR) {
> - reg = I40E_READ_REG(hw, I40E_PRTQF_FD_INSET(pctype,
> 1));
> - reg <<= I40E_32_BIT_WIDTH;
> - reg |= I40E_READ_REG(hw, I40E_PRTQF_FD_INSET(pctype,
> 0));
> - }
> -
> - return reg;
> -}
> -
> static void
> i40e_check_write_reg(struct i40e_hw *hw, uint32_t addr, uint32_t val)
> { @@ -6876,103 +6857,96 @@ i40e_check_write_reg(struct i40e_hw *hw,
> uint32_t addr, uint32_t val)
> (uint32_t)I40E_READ_REG(hw, addr)); }
>
> -static int
> -i40e_set_hash_inset_mask(struct i40e_hw *hw,
> - enum i40e_filter_pctype pctype,
> - enum rte_filter_input_set_op op,
> - uint32_t *mask_reg,
> - uint8_t num)
> +int
> +i40e_hash_filter_inset_select(struct i40e_hw *hw,
> + struct rte_eth_input_set_conf *conf)
> {
> - uint32_t reg;
> - uint8_t i;
> + struct i40e_pf *pf = &((struct i40e_adapter *)hw->back)->pf;
If you have check of 'if (!hw || !conf)', above line is not good.
> + enum i40e_filter_pctype pctype;
> + uint64_t input_set, inset_reg = 0;
> + uint32_t mask_reg[I40E_INSET_MASK_NUM_REG] = {0};
> + int ret, i, num;
>
> - if (!mask_reg || num > RTE_ETH_INPUT_SET_SELECT)
> + if (!hw || !conf) {
Check hw might not be needed at all.
[dpdk-dev] [PATCH 01/10] ethdev: add a generic flow and new behavior switch to fdir
Hi Jingjing, On Wednesday, February 02/24/16, 2016 at 19:26:54 -0800, Wu, Jingjing wrote: > > > > -Original Message- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Rahul Lakkireddy > > Sent: Wednesday, February 03, 2016 4:32 PM > > To: dev at dpdk.org > > Cc: Kumar Sanghvi; Nirranjan Kirubaharan > > Subject: [dpdk-dev] [PATCH 01/10] ethdev: add a generic flow and new > > behavior switch to fdir > > > > Add a new raw packet flow that allows specifying generic flow input. > > > > Add the ability to provide masks for fields in flow to allow range of > > values. > > > > Add a new behavior switch. > > > > Add the ability to provide behavior arguments to allow rewriting matched > > fields with new values. Ex: allows to provide new ip and port addresses to > > rewrite the fields of packets matching a filter rule before NAT'ing. > > > > Signed-off-by: Rahul Lakkireddy > > Signed-off-by: Kumar Sanghvi > > --- > > doc/guides/rel_notes/release_2_3.rst | 3 +++ > > lib/librte_ether/rte_eth_ctrl.h | 15 ++- > > 2 files changed, 17 insertions(+), 1 deletion(-) > > > > diff --git a/doc/guides/rel_notes/release_2_3.rst > > b/doc/guides/rel_notes/release_2_3.rst > > index 99de186..19ce954 100644 > > --- a/doc/guides/rel_notes/release_2_3.rst > > +++ b/doc/guides/rel_notes/release_2_3.rst > > @@ -39,6 +39,9 @@ API Changes > > ABI Changes > > --- > > > > +* New flow type ``RTE_ETH_FLOW_RAW_PKT`` had been introduced and > > hence > > + ``RTE_ETH_FLOW_MAX`` had been increased to 19. > > + > > > Great to see a raw_pkt_flow type. > And there is already a flow type "RTE_ETH_FLOW_RAW", it's not necessary to > add a new one. I added a new type based on your feedback only http://permalink.gmane.org/gmane.comp.networking.dpdk.devel/31386 So, do you want me to revert this change and use RTE_ETH_FLOW_RAW instead ? Thanks, Rahul.
[dpdk-dev] [PATCH 01/10] ethdev: add a generic flow and new behavior switch to fdir
Hi Thomas, On Wednesday, February 02/24/16, 2016 at 14:17:58 -0800, Thomas Monjalon wrote: > Caution: I truly respect the work done by Chelsio on DPDK. Thank you. And Chelsio will continue to support DPDK community and will continue to contribute. > And I'm sure you can help to build a good filtering API, which > was mainly designed with Intel needs in mind because it was > difficult to have opinions of other vendors some time ago. > That's why it's a chance to have new needs and it would be a shame > to let it go through a vendor specific backdoor. I agree that new needs should be raised. RFC v1 was submitted at: http://permalink.gmane.org/gmane.comp.networking.dpdk.devel/29986 RFC v2 was submitted at: http://permalink.gmane.org/gmane.comp.networking.dpdk.devel/30732 I tried to accomodate as many fields as possible to make this as generic as possible. Also, I followed the review comments given by Jingjing. I also waited for more review comments before posting this series to see if there were any objections with the approach. I have been trying to make this generic for all vendors and not favour any one over the other. > > 2016-02-25 00:10, Rahul Lakkireddy: > > Hi Thomas, > > > > On Wednesday, February 02/24/16, 2016 at 07:02:42 -0800, Thomas Monjalon > > wrote: > > > 2016-02-24 14:43, Bruce Richardson: > > > > On Wed, Feb 03, 2016 at 02:02:22PM +0530, Rahul Lakkireddy wrote: > > > > > Add a new raw packet flow that allows specifying generic flow input. > > > > > > > > > > Add the ability to provide masks for fields in flow to allow range of > > > > > values. > > > > > > > > > > Add a new behavior switch. > > > > > > > > > > Add the ability to provide behavior arguments to allow rewriting > > > > > matched > > > > > fields with new values. Ex: allows to provide new ip and port > > > > > addresses > > > > > to rewrite the fields of packets matching a filter rule before > > > > > NAT'ing. > > > > > > > > > Thomas, any comments as ethdev maintainer? > > > > > > Yes, some comments. > > > First, there are several different changes in the same patch. It must be > > > split. > > > > Should each structure change be split into a separate patch? > > A patch = a feature. > The switch action and the flow rule are different things. Ok. I will split this into separate patches. > > > > Then I don't understand at all the raw flow filter. What is a raw flow? > > > How behavior_arg must be used? > > > > This was discussed with Jingjing at > > > > http://permalink.gmane.org/gmane.comp.networking.dpdk.devel/31471 > > Thanks, I missed it. > > > A raw flow provides a generic way for vendors to add their vendor > > specific input flow. > > Please, "generic" and "vendor specific" in the same sentence. > It's obviously wrong. I think this sentence is being mis-interpreted. What I intended to say is: the fields are generic so that any vendor can hook-in. The fields themselves are not vendor specific. > > > In our case, it is possible to match several flows > > in a single rule. For example, it's possible to set an ethernet, vlan, > > ip and tcp/udp flows all in a single rule. We can specify all of these > > flows in a single raw input flow, which can then be passed to cxgbe flow > > director to set the corresponding filter. > > I feel we need to define what is an API. > If the application wants to call something specific to the NIC, why using > the ethdev API? You just have to include cxgbe.h. Well, in that sense, flow-director is also very intel specific, no ? What we are trying to do is make flow-director generic and, we have been following the review comments on this. If there are better ideas on how to achieve this, we are open to suggestions/comments and are ready to re-do the series and re-submit also. > > > On similar lines, behavior_arg provides a generic way to pass extra > > action arguments for matched flows. For example, in our case, to > > perform NAT, the new src/dst ip and src/dst port addresses to be > > re-written for a matched rule can be passed in behavior_arg. > > Yes a kind of void* to give what you want to the driver without the > convenience of a documented function. void* approach was taken based on review comments from Jingjing. And we didn't receive any further comments/objections on that thread. > > I know the support of filters among NICs is really heterogeneous. > And the DPDK API are not yet generic enough. But please do not give up! > If the filtering API can be improved to support your cases, please do it. I am not giving up. If there are better suggestions then, I am willing to re-do and re-submit the series. If the approach taken in RFC v1 series looks more promising then, I can re-surrect that also. However, I will need some direction over here so that it becomes generic and doesn't remain intel specific as it is now. Thanks, Rahul.
[dpdk-dev] [PATCH v2] cxgbe: fix to copy pci info to ports under same PF
Chelsio NIC ports share a single PF. Move rte_eth_copy_pci_info()
to copy the pci device information to the remaining ports as well.
Also update license year to 2016.
Fixes: eeefe73f0af1 ("drivers: copy PCI device info to ethdev data")
Signed-off-by: Rahul Lakkireddy
Signed-off-by: Kumar Sanghvi
---
v2:
- Dropped the separate patch that updated license year for unmodified
CXGBE related files.
drivers/net/cxgbe/cxgbe_ethdev.c | 4 +---
drivers/net/cxgbe/cxgbe_main.c | 5 -
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/cxgbe/cxgbe_ethdev.c b/drivers/net/cxgbe/cxgbe_ethdev.c
index 97ef152..8b63e16 100644
--- a/drivers/net/cxgbe/cxgbe_ethdev.c
+++ b/drivers/net/cxgbe/cxgbe_ethdev.c
@@ -1,7 +1,7 @@
/*-
* BSD LICENSE
*
- * Copyright(c) 2014-2015 Chelsio Communications.
+ * Copyright(c) 2014-2016 Chelsio Communications.
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -819,8 +819,6 @@ static int eth_cxgbe_dev_init(struct rte_eth_dev *eth_dev)
pci_dev = eth_dev->pci_dev;
- rte_eth_copy_pci_info(eth_dev, pci_dev);
-
snprintf(name, sizeof(name), "cxgbeadapter%d", eth_dev->data->port_id);
adapter = rte_zmalloc(name, sizeof(*adapter), 0);
if (!adapter)
diff --git a/drivers/net/cxgbe/cxgbe_main.c b/drivers/net/cxgbe/cxgbe_main.c
index 649b941..9321cbe 100644
--- a/drivers/net/cxgbe/cxgbe_main.c
+++ b/drivers/net/cxgbe/cxgbe_main.c
@@ -1,7 +1,7 @@
/*-
* BSD LICENSE
*
- * Copyright(c) 2014-2015 Chelsio Communications.
+ * Copyright(c) 2014-2016 Chelsio Communications.
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -1166,6 +1166,9 @@ allocate_mac:
pi->eth_dev->dev_ops = adapter->eth_dev->dev_ops;
pi->eth_dev->tx_pkt_burst = adapter->eth_dev->tx_pkt_burst;
pi->eth_dev->rx_pkt_burst = adapter->eth_dev->rx_pkt_burst;
+
+ rte_eth_copy_pci_info(pi->eth_dev, pi->eth_dev->pci_dev);
+
TAILQ_INIT(&pi->eth_dev->link_intr_cbs);
pi->eth_dev->data->mac_addrs = rte_zmalloc(name,
--
2.5.3
[dpdk-dev] [PATCH v3 1/3] fm10k: enable FTAG based forwarding
Hi, Bruce, Thomas, Best Regards, Mark > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon > Sent: Thursday, February 25, 2016 12:38 AM > To: Richardson, Bruce; Wang, Xiao W > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH v3 1/3] fm10k: enable FTAG based > forwarding > > 2016-02-24 15:42, Bruce Richardson: > > On Thu, Feb 04, 2016 at 11:38:47AM +0800, Wang Xiao W wrote: > > > 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 > > > > Any comments on this patch? > > > > My thoughts: is there a way in which this could be done without adding in a > new > > build time config option? > > Bruce, it's simpler to explain that build time options are forbidden to > enable such options. > Or the terrific kid's approach: one day, the Big Build-Option Eater will come > and will eat every undecided features! ;) This feature is trying to use FTAG (a unique tech in fm10k) instead of mac/vlan to forward packets. App need a way to tell PMD driver that which forwarding style it would like to use. So, the best option is to let packets carry a flag in mbuf to tell drive in fast path. You can see that this is unique to fm10k and we thought community won't like to see this flag introduced into mbuf. If you do agree, we can introduce a new flag. So, we step backwards and assume customer will use static configurations to enable this feature. After it is enabled, we'll assume app will use FTAG for all packets.
[dpdk-dev] [PATCH v4 1/1] examples/l3fwd: modify and modularize l3fwd code
The main problem with l3fwd is that it is too monolithic with everything
being
in one file, and the various options all controlled by compile time
flags. This
means that it's hard to read and understand, and when making any
changes, you need
to go to a lot of work to try and ensure you cover all the code paths,
since a
compile of the app will not touch large parts of the l3fwd codebase.
Following changes were done to fix the issues mentioned above
> Split out the various lpm and hash specific functionality into
separate
files, so that l3fwd code has one file for common code e.g. args
processing, mempool creation, and then individual files for the
various
forwarding approaches.
Following are new file lists
main.c (Common code for args processing, memppol creation, etc)
l3fwd_em.c (Hash/Exact match aka 'EM' functionality)
l3fwd_em_sse.h (SSE4_1 buffer optimizated 'EM' code)
l3fwd_lpm.c (Longest Prefix Match aka 'LPM' functionality)
l3fwd_lpm_sse.h (SSE4_1 buffer optimizated 'LPM' code)
l3fwd.h (Common include for 'EM' and 'LPM')
> The choosing of the lpm/hash path should be done at runtime, not
compile time, via a command-line argument. This will ensure that
both code paths get compiled in a single go
Following examples show runtime options provided
Select 'LPM' or 'EM' based on run time selection f.e.
> l3fwd -c 0x1 -n 1 -- -p 0x1 -E ... (EM)
> l3fwd -c 0x1 -n 1 -- -p 0x1 -L ... (LPM)
Options "E" and "L" are mutualy-exclusive.
If none selected, "L" is default.
Signed-off-by: Ravi Kerur
Signed-off-by: Piotr Azarewicz
Tested-by: Tomasz Kulasek
Acked-by: Tomasz Kulasek
Acked-by: Konstantin Ananyev
---
v4 changes:
fix compilation for i686
examples/l3fwd/l3fwd_em.c:437:2: error:
format '%llx' expects argument of type 'long long unsigned int',
but argument 2 has type 'unsigned int'
solution:
-printf("Hash: Adding 0x%" PRIx64 " keys\n", IPV4_L3FWD_EM_NUM_ROUTES);
+printf("Hash: Adding 0x%" PRIx64 " keys\n",
(uint64_t)IPV4_L3FWD_EM_NUM_ROUTES);
v3 changes:
add missed fix 'fix build without SSE4.1':
- move l3fwd_lpm_no_opt_send_packets() to l3fwd_lpm.h
- move l3fwd_em_no_opt_send_packets() to l3fwd_em.h
- add #elses which provide proper headers respectively
l3fwd_lpm.h/l3fwd_em.h or l3fwd_lpm_sse.h/l3fwd_em_sse.h
v2 changes:
rebase to latest code
examples/l3fwd/Makefile| 11 +-
examples/l3fwd/l3fwd.h | 211
examples/l3fwd/l3fwd_em.c | 751 ++
examples/l3fwd/l3fwd_em.h | 66 ++
examples/l3fwd/l3fwd_em_sse.h | 479 +
examples/l3fwd/l3fwd_lpm.c | 305 ++
examples/l3fwd/l3fwd_lpm.h | 151 +++
examples/l3fwd/l3fwd_lpm_sse.h | 610 +++
examples/l3fwd/main.c | 2209
9 files changed, 2785 insertions(+), 2008 deletions(-)
create mode 100644 examples/l3fwd/l3fwd.h
create mode 100644 examples/l3fwd/l3fwd_em.c
create mode 100644 examples/l3fwd/l3fwd_em.h
create mode 100644 examples/l3fwd/l3fwd_em_sse.h
create mode 100644 examples/l3fwd/l3fwd_lpm.c
create mode 100644 examples/l3fwd/l3fwd_lpm.h
create mode 100644 examples/l3fwd/l3fwd_lpm_sse.h
diff --git a/examples/l3fwd/Makefile b/examples/l3fwd/Makefile
index 68de8fc..5ce0ce0 100644
--- a/examples/l3fwd/Makefile
+++ b/examples/l3fwd/Makefile
@@ -1,6 +1,6 @@
# BSD LICENSE
#
-# Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+# Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
@@ -42,15 +42,10 @@ include $(RTE_SDK)/mk/rte.vars.mk
APP = l3fwd
# all source are stored in SRCS-y
-SRCS-y := main.c
+SRCS-y := main.c l3fwd_lpm.c l3fwd_em.c
+CFLAGS += -I$(SRCDIR)
CFLAGS += -O3 $(USER_FLAGS)
CFLAGS += $(WERROR_FLAGS)
-# workaround for a gcc bug with noreturn attribute
-# http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12603
-ifeq ($(CONFIG_RTE_TOOLCHAIN_GCC),y)
-CFLAGS_main.o += -Wno-return-type
-endif
-
include $(RTE_SDK)/mk/rte.extapp.mk
diff --git a/examples/l3fwd/l3fwd.h b/examples/l3fwd/l3fwd.h
new file mode 100644
index 000..f450269
--- /dev/null
+++ b/examples/l3fwd/l3fwd.h
@@ -0,0 +1,211 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
+ * 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 follow
[dpdk-dev] [PATCH v2 12/12] examples/l3fwd: add option to parse ptype
Hi Konstantin,
On 1/15/2016 10:47 PM, Ananyev, Konstantin wrote:
> Hi Jianfeng,
>
>> -Original Message-
>> From: Tan, Jianfeng
>> Sent: Friday, January 15, 2016 5:46 AM
>> To: dev at dpdk.org
>> Cc: Zhang, Helin; Ananyev, Konstantin; Tan, Jianfeng
>> Subject: [PATCH v2 12/12] examples/l3fwd: add option to parse ptype
>>
>> As a example to use ptype info, l3fwd needs firstly to use
>> rte_eth_dev_get_ptype_info() API to check if device and/or PMD driver will
>> parse and fill the needed packet type. If not, use the newly added option,
>> --parse-ptype, to analyze it in the callback softly.
>>
>> Signed-off-by: Jianfeng Tan
>> ---
>> examples/l3fwd/main.c | 91
>> +++
>> 1 file changed, 91 insertions(+)
>>
...
>> +static inline void
>> +parse_packet_type(struct rte_mbuf *m)
>> +{
>> +struct ether_hdr *eth_hdr;
>> +uint32_t packet_type = 0;
>> +uint16_t ethertype;
>> +
>> +eth_hdr = rte_pktmbuf_mtod(m, struct ether_hdr *);
>> +ethertype = rte_be_to_cpu_16(eth_hdr->ether_type);
>> +switch (ethertype) {
>> +case ETHER_TYPE_IPv4:
>> +packet_type |= RTE_PTYPE_L3_IPV4_EXT_UNKNOWN;
>> +break;
>> +case ETHER_TYPE_IPv6:
>> +packet_type |= RTE_PTYPE_L3_IPV6_EXT_UNKNOWN;
>> +break;
> That's enough for LPM, for EM, don't we need to be sure there are no
> extensions
> in the IP header?
>
> Konstantin
Yes, EM needs to differentiate RTE_PTYPE_L3_IPV4/RTE_PTYPE_L3_IPV4_EXT,
RTE_PTYPE_L3_IPV6/RTE_PTYPE_L3_IPV6_EXT:
a. for soft ptype parser here, I'll add the code to do it.
b. for hardware ptype parser, things become complex:
those NICs which can differentiate:
e1000
fmf10k
ixgbe
those NICs which cannot differentiate:
cxgbe (ipv4, ipv6)
enic (ipv4, ipv6)
i40e (ipv4_ext_unknown, ipv6_ext_unknown)
mlx4 (ipv4, ipv6)
mlx5 (ipv4, ipv6)
nfp (ipv4, ipv6, ipv6_ext)
vmxnet3 (ipv4, ipv4_ext)
As a result, l3fwd can only work perfectly on those NICs which can
differentiate.
SO if we really do the strict checking?
Thanks,
Jianfeng
[dpdk-dev] [PATCH v2 12/12] examples/l3fwd: add option to parse ptype
Hi Jianfeng,
> -Original Message-
> From: Tan, Jianfeng
> Sent: Thursday, February 25, 2016 10:41 AM
> To: Ananyev, Konstantin; dev at dpdk.org
> Cc: Zhang, Helin
> Subject: Re: [PATCH v2 12/12] examples/l3fwd: add option to parse ptype
>
> Hi Konstantin,
>
> On 1/15/2016 10:47 PM, Ananyev, Konstantin wrote:
> > Hi Jianfeng,
> >
> >> -Original Message-
> >> From: Tan, Jianfeng
> >> Sent: Friday, January 15, 2016 5:46 AM
> >> To: dev at dpdk.org
> >> Cc: Zhang, Helin; Ananyev, Konstantin; Tan, Jianfeng
> >> Subject: [PATCH v2 12/12] examples/l3fwd: add option to parse ptype
> >>
> >> As a example to use ptype info, l3fwd needs firstly to use
> >> rte_eth_dev_get_ptype_info() API to check if device and/or PMD driver will
> >> parse and fill the needed packet type. If not, use the newly added option,
> >> --parse-ptype, to analyze it in the callback softly.
> >>
> >> Signed-off-by: Jianfeng Tan
> >> ---
> >> examples/l3fwd/main.c | 91
> >> +++
> >> 1 file changed, 91 insertions(+)
> >>
> ...
> >> +static inline void
> >> +parse_packet_type(struct rte_mbuf *m)
> >> +{
> >> + struct ether_hdr *eth_hdr;
> >> + uint32_t packet_type = 0;
> >> + uint16_t ethertype;
> >> +
> >> + eth_hdr = rte_pktmbuf_mtod(m, struct ether_hdr *);
> >> + ethertype = rte_be_to_cpu_16(eth_hdr->ether_type);
> >> + switch (ethertype) {
> >> + case ETHER_TYPE_IPv4:
> >> + packet_type |= RTE_PTYPE_L3_IPV4_EXT_UNKNOWN;
> >> + break;
> >> + case ETHER_TYPE_IPv6:
> >> + packet_type |= RTE_PTYPE_L3_IPV6_EXT_UNKNOWN;
> >> + break;
> > That's enough for LPM, for EM, don't we need to be sure there are no
> > extensions
> > in the IP header?
> >
> > Konstantin
>
> Yes, EM needs to differentiate RTE_PTYPE_L3_IPV4/RTE_PTYPE_L3_IPV4_EXT,
> RTE_PTYPE_L3_IPV6/RTE_PTYPE_L3_IPV6_EXT:
> a. for soft ptype parser here, I'll add the code to do it.
>
> b. for hardware ptype parser, things become complex:
> those NICs which can differentiate:
> e1000
> fmf10k
> ixgbe
> those NICs which cannot differentiate:
> cxgbe (ipv4, ipv6)
> enic (ipv4, ipv6)
> i40e (ipv4_ext_unknown, ipv6_ext_unknown)
Yep, I am aware about that difference between i40e and rest of Intel PMDs :(
> mlx4 (ipv4, ipv6)
> mlx5 (ipv4, ipv6)
> nfp (ipv4, ipv6, ipv6_ext)
> vmxnet3 (ipv4, ipv4_ext)
>
> As a result, l3fwd can only work perfectly on those NICs which can
> differentiate.
Well, we can do a SW parsing for that NICs,
but I presume it might slowdown things quite a bit.
>
> SO if we really do the strict checking?
Ok, but then we probably need to put into SA guide that l3fwd EM
not supposed to work with IP with extentions.
Konstantin
>
> Thanks,
> Jianfeng
[dpdk-dev] [PATCH v2 07/12] pmd/ixgbe: add dev_ptype_info_get implementation
> >>
> >> +static int
> >> +ixgbe_dev_ptype_info_get(struct rte_eth_dev *dev, uint32_t ptypes[])
> >> +{
> >> + int num = 0;
> >> +
> >> + if (dev->rx_pkt_burst == ixgbe_recv_pkts ||
> >> + dev->rx_pkt_burst == ixgbe_recv_pkts_lro_single_alloc ||
> >> + dev->rx_pkt_burst == ixgbe_recv_pkts_lro_bulk_alloc ||
> >> + dev->rx_pkt_burst == ixgbe_recv_pkts_bulk_alloc ||
> >> + dev->rx_pkt_burst == ixgbe_recv_pkts_vec ||
> >> + dev->rx_pkt_burst == ixgbe_recv_scattered_pkts_vec) {
> > Is there any point in that big if above?
> > All ixgbe recv functions support ptype recognition, so why to have it at
> > all?
> > Same question for igb.
> > Konstantin
>
> I'd like this code to put it explicitly instead of an "if
> (dev->rx_pkt_burst)" to indicate that all ixgbe recv functions supports
> these ptypes.
>
> Is it make sense?
It seems a bit of overhead to me, but if you would like to keep it as it is,
I wouldn't insist.
Konstantin
[dpdk-dev] [PATCH v2 01/12] ethdev: add API to query packet type filling info
> >> +int
> >> +rte_eth_dev_get_ptype_info(uint8_t port_id, uint32_t ptype_mask,
> >> + uint32_t ptypes[], int num)
> >> +{
> >> + int ret, i, j;
> >> + struct rte_eth_dev *dev;
> >> + uint32_t all_ptypes[RTE_PTYPE_MAX_NUM];
> >> +
> >> + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> >> + dev = &rte_eth_devices[port_id];
> >> + RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_ptype_info_get, -ENOTSUP);
> >> + ret = (*dev->dev_ops->dev_ptype_info_get)(dev, all_ptypes);
> >> +
> >> + for (i = 0, j = 0; i < ret && j < num; ++i)
> >> + if (all_ptypes[i] & ptype_mask)
> >> + ptypes[j++] = all_ptypes[i];
> >> +
> >> + return ret;
> > I think it needs to be something like:
> >
> > j = 0;
> > for (i = 0, j = 0; i < ret; ++i) {
> > if (all_ptypes[i] & ptype_mask) {
> >if (j < num)
> > ptypes[j] = all_ptypes[i];
> >j++;
> > }
> > }
> >
> > return j;
> >
> > Konstantin
> >
>
> You are right, my previous code is wrong.
> But I have a concern about your code above: under the condition that the
> caller does not provide big enough array to store adequate ptypes, it
> has no way to return the not-enough-memory message back to caller.
>
> So under that condition, how about we just return -ENOMEM?
>
As I remember, the agreement was - we don't return an -ENOMEM in that case.
What we do return - number of entries in ptypes[] that would be required to
store all adequate ptypes (similar to what snprinf() does).
So the user can do something like that (if he needs to):
num = rte_eth_dev_get_ptype_info(port, ptype_mask, NULL, 0);
if (num < 0) {/*error handling*/}
ptypes = alloca(num * ptypes[0]);
n = rte_eth_dev_get_ptype_info(port, ptype_mask, ptypes, num);
...
Konstantin
[dpdk-dev] virtio PMD is not working with master version
Hello,
I am trying to connect two virtual machines through Open vSwitch using
vhost-user ports, on the host side everything looks fine.
When using the standard virtio drivers both virtual machines are able to
exchange traffic, but when I load the virtio PMD and run a DPDK application
it shows the following error message:
...
EAL: PCI device :00:04.0 on NUMA socket -1
EAL: probe driver: 1af4:1000 rte_virtio_pmd
EAL: PCI memory mapped at 0x7f892dc0
PMD: virtio_read_caps(): [40] skipping non VNDR cap id: 11
PMD: virtio_read_caps(): no modern virtio pci device found.
PMD: vtpci_init(): trying with legacy virtio pci.
EAL: eal_parse_sysfs_value(): cannot open sysfs value
/sys/bus/pci/devices/:00:04.0/uio/uio0/portio/port0/start
EAL: pci_uio_ioport_map(): cannot parse portio start
EAL: Error - exiting with code: 1
Cause: Requested device :00:04.0 cannot be used
...
I tried it using the master version of DPDK, when I use the 2.2 version it
works without problems:
...
PMD: parse_sysfs_value(): parse_sysfs_value(): cannot open sysfs value
/sys/bus/pci/devices/:00:04.0/uio/uio0/portio/port0/size
PMD: virtio_resource_init_by_uio(): virtio_resource_init_by_uio(): cannot
parse size
PMD: virtio_resource_init_by_ioports(): PCI Port IO found start=0xc100 with
size=0x20
PMD: virtio_negotiate_features(): guest_features before negotiate = cf8020
PMD: virtio_negotiate_features(): host_features before negotiate = 40268020
PMD: virtio_negotiate_features(): features after negotiate = 68020
PMD: eth_virtio_dev_init(): PORT MAC: 00:00:00:00:00:11
PMD: eth_virtio_dev_init(): VIRTIO_NET_F_STATUS is not supported
PMD: eth_virtio_dev_init(): VIRTIO_NET_F_MQ is not supported
PMD: virtio_dev_cq_queue_setup(): >>
PMD: virtio_dev_queue_setup(): selecting queue: 2
PMD: virtio_dev_queue_setup(): vq_size: 64 nb_desc:0
PMD: virtio_dev_queue_setup(): vring_size: 4612, rounded_vring_size: 8192
PMD: virtio_dev_queue_setup(): vq->vq_ring_mem: 0x76d43000
PMD: virtio_dev_queue_setup(): vq->vq_ring_virt_mem: 0x7fa669743000
PMD: eth_virtio_dev_init(): config->max_virtqueue_pairs=1
PMD: eth_virtio_dev_init(): config->status=0
PMD: eth_virtio_dev_init(): PORT MAC: 00:00:00:00:00:11
PMD: eth_virtio_dev_init(): hw->max_rx_queues=1 hw->max_tx_queues=1
PMD: eth_virtio_dev_init(): port 0 vendorID=0x1af4 deviceID=0x1000
PMD: virtio_dev_vring_start(): >>
...
According to git bisect it appears to be that it does not work anymore
after the b8f04520ad71 ("virtio: use PCI ioport API") commit.
I also tried to run the "Vhost Sample Application" in the host with the
test-pmd in the guest, the problem is the same.
I am using:
QEMU v2.2.1
guest kernel: Linux ubuntu 3.19.0-25-generic
Both guest and host use 2MB huge pages
The qemu command line is
DEVICE_CMD="-chardev
socket,id=char2,path=/usr/local/var/run/openvswitch/vhost-user-2 \
-netdev type=vhost-user,id=mynet2,chardev=char2,vhostforce \
-device virtio-net-pci,mac=00:00:00:00:00:11,netdev=mynet2"
MEMORY_CMD="-object
memory-backend-file,id=mem,size=1024M,mem-path=/dev/hugepages,share=on
-numa node,memdev=mem -mem-prealloc"
qemu-system-x86_64 ... -cpu host -smp 3 -machine accel=kvm,usb=off
$MEMORY_CMD -m 1024 $DEVICE_CMD -monitor stdio
Could you check if this happens also to you?
Thank you very much.
[dpdk-dev] virtio PMD is not working with master version
On Thu, Feb 25, 2016 at 5:00 PM, Mauricio V?squez wrote: > Hello, > > I am trying to connect two virtual machines through Open vSwitch using > vhost-user ports, on the host side everything looks fine. > When using the standard virtio drivers both virtual machines are able to > exchange traffic, but when I load the virtio PMD and run a DPDK application > it shows the following error message: > > ... > EAL: PCI device :00:04.0 on NUMA socket -1 > EAL: probe driver: 1af4:1000 rte_virtio_pmd > EAL: PCI memory mapped at 0x7f892dc0 > PMD: virtio_read_caps(): [40] skipping non VNDR cap id: 11 > PMD: virtio_read_caps(): no modern virtio pci device found. > PMD: vtpci_init(): trying with legacy virtio pci. > EAL: eal_parse_sysfs_value(): cannot open sysfs value > /sys/bus/pci/devices/:00:04.0/uio/uio0/portio/port0/start > EAL: pci_uio_ioport_map(): cannot parse portio start > EAL: Error - exiting with code: 1 > Cause: Requested device :00:04.0 cannot be used > ... > hmmm, Resource error log has nothing to do with ovs, I tested tip-of-tree for testpmd for ioport mode, no interface attached. Couldn't see those error.
[dpdk-dev] [PATCH v2] ixgbe: fix link down issue on x550em_x
On Thu, Feb 25, 2016 at 01:32:33AM +, Lu, Wenzhuo wrote: > Hi Bruce, > > > -Original Message- > > From: Richardson, Bruce > > Sent: Wednesday, February 24, 2016 10:26 PM > > To: He, Shaopeng > > Cc: Lu, Wenzhuo; dev at dpdk.org > > Subject: Re: [dpdk-dev] [PATCH v2] ixgbe: fix link down issue on x550em_x > > > > On Thu, Feb 04, 2016 at 06:21:04AM +, He, Shaopeng wrote: > > > > > > > -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 > > > > > I'm a bit confused regarding the commit message and the code in the patch. > > The commit message talks about enabling speed auto-negotiation, while the > > code never refers to any such thing. Instead all we have are settings for > > manipulating interrupt masks to enable PHY interrupts. I think some > > additional > > information is needed to connect A and B together here. > The reason is that the handler of the link speed auto-neg is already in the > base code. It's ixgbe_handle_lasi. > What we need is a trigger. When the advertised link speed changes, a PHY > interruption will be triggered. So, we should handle this interruption and > call ixgbe_handle_lasi to set the link speed correct. > Let me add more explanation in the commit log. > Yes, please do. What you have just explained makes much more sense and should be included in the log. > > > > A second, more minor nit is that the commit title never refers to link auto- > > negotiation, but refers to this as a bug fix - which is also correct. If > > this is > > primarily a bug fix, please include a fixes line if possible, but please > > also refer to > > auto-neg in the title if possible too. > I didn't add a fixes line because it doesn't fix an issue introduced by SW, > or even FW, HW. As said in commit log, we hit a link down issue, but the root > cause is the link speed auto-neg is not supported on this specific NIC. > On the other NICs, link speed auto-neg is supported by FW, SW need no do > anything. So we didn't implement the link speed auto-neg. But we have to > implement this feature on this NIC for FW doesn't implement it. > Should I change the tittle to "support link speed auto-neg on x550em_x"? > Yes, that is probably better. Thanks, /Bruce
[dpdk-dev] virtio PMD is not working with master version
On Thu, Feb 25, 2016 at 12:30 PM, Mauricio V?squez
wrote:
> ...
> EAL: PCI device :00:04.0 on NUMA socket -1
> EAL: probe driver: 1af4:1000 rte_virtio_pmd
> EAL: PCI memory mapped at 0x7f892dc0
> PMD: virtio_read_caps(): [40] skipping non VNDR cap id: 11
> PMD: virtio_read_caps(): no modern virtio pci device found.
> PMD: vtpci_init(): trying with legacy virtio pci.
> EAL: eal_parse_sysfs_value(): cannot open sysfs value
> /sys/bus/pci/devices/:00:04.0/uio/uio0/portio/port0/start
> EAL: pci_uio_ioport_map(): cannot parse portio start
> EAL: Error - exiting with code: 1
> Cause: Requested device :00:04.0 cannot be used
> ...
[snip]
> ...
> PMD: parse_sysfs_value(): parse_sysfs_value(): cannot open sysfs value
> /sys/bus/pci/devices/:00:04.0/uio/uio0/portio/port0/size
> PMD: virtio_resource_init_by_uio(): virtio_resource_init_by_uio(): cannot
> parse size
> PMD: virtio_resource_init_by_ioports(): PCI Port IO found start=0xc100 with
> size=0x20
[snip]
>
> According to git bisect it appears to be that it does not work anymore after
> the b8f04520ad71 ("virtio: use PCI ioport API") commit.
>From the logs, I would say I broke uio_pci_generic since we are in
"uio" case, but uio portio sysfs does not exist.
virtio pmd fell back to ioports discovery before my change.
Problem can be workaround for now by unbinding your device from
uio_pci_generic or on the contrary bind to igb_uio.
I've been sick at home, all this week.
Will see next week for a fix unless someone sends one.
--
David Marchand
[dpdk-dev] [PATCH v3 1/3] fm10k: enable FTAG based forwarding
On Thu, Feb 25, 2016 at 10:04:02AM +, Chen, Jing D wrote: > Hi, Bruce, Thomas, > > Best Regards, > Mark > > > -Original Message- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon > > Sent: Thursday, February 25, 2016 12:38 AM > > To: Richardson, Bruce; Wang, Xiao W > > Cc: dev at dpdk.org > > Subject: Re: [dpdk-dev] [PATCH v3 1/3] fm10k: enable FTAG based > > forwarding > > > > 2016-02-24 15:42, Bruce Richardson: > > > On Thu, Feb 04, 2016 at 11:38:47AM +0800, Wang Xiao W wrote: > > > > 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 > > > > > > Any comments on this patch? > > > > > > My thoughts: is there a way in which this could be done without adding in > > > a > > new > > > build time config option? > > > > Bruce, it's simpler to explain that build time options are forbidden to > > enable such options. > > Or the terrific kid's approach: one day, the Big Build-Option Eater will > > come > > and will eat every undecided features! ;) > > This feature is trying to use FTAG (a unique tech in fm10k) instead of > mac/vlan > to forward packets. App need a way to tell PMD driver that which forwarding > style it would like to use. Why not just specify this in the port configuration at setup time? > So, the best option is to let packets carry a flag in mbuf to tell drive in > fast path. > You can see that this is unique to fm10k and we thought community won't like > to see > this flag introduced into mbuf. If you do agree, we can introduce a new flag. Why does it need to be specified per-mbuf? The existing config flag added is global, so a per-mbuf flag shouldn't be needed to get equivalent behaviour. > So, we step backwards and assume customer will use static configurations to > enable > this feature. After it is enabled, we'll assume app will use FTAG for all > packets. Yes, but instead of compile time option, why not port config-time option instead? /Bruce
[dpdk-dev] [PATCH v2] cxgbe: fix to copy pci info to ports under same PF
On Thu, Feb 25, 2016 at 03:07:53PM +0530, Rahul Lakkireddy wrote:
> Chelsio NIC ports share a single PF. Move rte_eth_copy_pci_info()
> to copy the pci device information to the remaining ports as well.
>
> Also update license year to 2016.
>
> Fixes: eeefe73f0af1 ("drivers: copy PCI device info to ethdev data")
>
> Signed-off-by: Rahul Lakkireddy
> Signed-off-by: Kumar Sanghvi
Applied to dpdk-next-net/rel_16_04
Thanks,
/Bruce
[dpdk-dev] [PATCH 02/10] examples/test-cxgbe-filters: add example to test cxgbe fdir support
On Thu, Feb 25, 2016 at 12:05:34AM +0530, Rahul Lakkireddy wrote: > Hi Bruce, > > On Wednesday, February 02/24/16, 2016 at 06:40:56 -0800, Bruce Richardson > wrote: > > On Wed, Feb 03, 2016 at 02:02:23PM +0530, Rahul Lakkireddy wrote: > > > Add a new test_cxgbe_filters command line example to test support for > > > Chelsio T5 hardware filtering. Shows how to pass the Chelsio input flow > > > and input masks. Also, shows how to pass extra behavior arguments to > > > rewrite fields in matched filter rules. > > > > > > Also add documentation and update MAINTAINERS. > > > > > > Signed-off-by: Rahul Lakkireddy > > > Signed-off-by: Kumar Sanghvi > > > > Hi, > > > > for testing NIC functionality, the "testpmd" app is what is used, and it > > already > > contains support for existing flow director functionality. Should the > > testing > > functionality not be included there? > > > > We initially thought of adding example by extending flow director in > testpmd itself. However, based on discussion at [1], we then created > a separate sample app for this considering each vendor would come up > with their own sample app. > > [1] http://permalink.gmane.org/gmane.comp.networking.dpdk.devel/31471 > Thanks for the old conversation link. I don't like the idea of having vendor specific sample apps, I think the samples should be as generic as possible. If there is a particular feature that you want to demonstrate in a sample app, then that is worthy of inclusion - assuming it's possible that in future more than one vendor's hardware will support the feature. Within the documentation for the particular NIC or driver, feel free to call out what features the NIC supports and how those should be configured. I hope this makes sense. We probably need a documented policy on how to go about adding new NIC feature support to ensure everyone is in agreement on how things should be done so as to allow vendors to expose the features of their hardware, while at the same time allowing users to write applications that can be generic across the various hardware platforms. Regards, /Bruce
[dpdk-dev] [PATCH v3 5/5] 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, February 18, 2016 3:18 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v3 5/5] 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.
>
> Also update release note for VxLAN & NVGRE checksum off-load support.
>
> Signed-off-by: Wenzhuo Lu
> ---
> doc/guides/rel_notes/release_2_3.rst | 8
> drivers/net/ixgbe/ixgbe_ethdev.c | 4
> drivers/net/ixgbe/ixgbe_rxtx.c | 18 --
> drivers/net/ixgbe/ixgbe_rxtx.h | 1 +
> 4 files changed, 29 insertions(+), 2 deletions(-)
>
> diff --git a/doc/guides/rel_notes/release_2_3.rst
> b/doc/guides/rel_notes/release_2_3.rst
> index 99de186..5dce7fb 100644
> --- a/doc/guides/rel_notes/release_2_3.rst
> +++ b/doc/guides/rel_notes/release_2_3.rst
> @@ -4,6 +4,14 @@ DPDK Release 2.3
> New Features
>
>
> +* **Added support for VxLAN & NVGRE checksum off-load on X550.**
> +
> + * Added support for VxLAN & NVGRE RX/TX checksum off-load on
> +X550. RX/TX checksum off-load is provided on both inner and
> +outer IP header and TCP header.
> + * Added functions to support VxLAN port configuration. The
> +default VxLAN port number is 4789 but this can be updated
> +programmatically.
>
> Resolved Issues
> ---
> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
> b/drivers/net/ixgbe/ixgbe_ethdev.c
> index fd9751e..3c3aa72 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> @@ -2811,6 +2811,10 @@ ixgbe_dev_info_get(struct rte_eth_dev *dev, struct
> rte_eth_dev_info *dev_info)
> DEV_TX_OFFLOAD_SCTP_CKSUM |
> DEV_TX_OFFLOAD_TCP_TSO;
>
> + if (hw->mac.type == ixgbe_mac_X550 ||
> + hw->mac.type == ixgbe_mac_X550EM_x)
> + dev_info->tx_offload_capa |= DEV_TX_OFFLOAD_OUTER_IPV4_CKSUM;
> +
> dev_info->default_rxconf = (struct rte_eth_rxconf) {
> .rx_thresh = {
> .pthresh = IXGBE_DEFAULT_RX_PTHRESH,
> diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c b/drivers/net/ixgbe/ixgbe_rxtx.c
> index 4ed9ddd..8eab768 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)
>
> static inline struct rte_mbuf *
> rte_rxmbuf_alloc(struct rte_mempool *mp)
> @@ -364,6 +365,7 @@ 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;
> @@ -430,6 +432,15 @@ 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.l2_len |= ~0;
> + seqnum_seed |= tx_offload.outer_l3_len
> +<< IXGBE_ADVTXD_OUTER_IPLEN;
> + seqnum_seed |= tx_offload.l2_len
> +<< IXGBE_ADVTXD_TUNNEL_LEN;
> + }
> +
> txq->ctx_cache[ctx_idx].flags = ol_flags;
> txq->ctx_cache[ctx_idx].tx_offload.data =
> tx_offload_mask.data & tx_offload.data;
> @@ -441,7 +452,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;
> }
>
> /*
> @@ -492,6 +503,8 @@ tx_desc_ol_flags_to_cmdtype(uint64_t ol_flags)
> cmdtype |= IXGBE_ADVTXD_DCMD_VLE;
> if (ol_flags & PKT_TX_TCP_SEG)
> cmdtype |= IXGBE_ADVTXD_DCMD_TSE;
> + if (ol_flags & PKT_TX_OUTER_IP_CKSUM)
> + cmdtype |= (1 << IXGBE_ADVTXD_OUTERIPCS_SHIFT);
> return cmdtype;
> }
>
> @@ -623,6 +636,7 @@ ixgbe_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts,
> tx_offload.l4_len = tx_pkt->l4_len;
> tx_offload.vlan_tci = tx_pkt->vlan_tci;
> tx_offload.tso_segsz = tx_pkt->tso_segsz;
> + tx_offload.outer_l3_len = tx_pkt->outer_l3_len;
>
> /* If new context need be built or reuse the exist ctx.
> */
> ctx = what_advctx_updat
[dpdk-dev] [PATCH v3 00/12] Add API to get packet type info
To achieve this, a new function pointer, dev_ptype_info_get, is added into struct eth_dev_ops. For those devices who do not implement it, it means it will not provide any ptype info. v3: - Change how to use this API: api to allocate mem for storing ptype array; and caller to free the mem. - Change how to return back ptypes from PMDs: return a pointer to corresponding static const array of supported ptypes, terminated by RTE_PTYPE_UNKNOWN. - Fix l3fwd parse_packet_type() when EXACT_MATCH is enabled. - Fix l3fwd memory leak when calling the API. v2: - Move ptype_mask filter function from each PMDs into ether layer. - Add ixgbe vPMD's ptype info. - Fix code style issues. Jianfeng Tan (12): ethdev: add API to query packet type filling info pmd/cxgbe: add dev_ptype_info_get implementation pmd/e1000: add dev_ptype_info_get implementation pmd/enic: add dev_ptype_info_get implementation pmd/fm10k: add dev_ptype_info_get implementation pmd/i40e: add dev_ptype_info_get implementation pmd/ixgbe: add dev_ptype_info_get implementation pmd/mlx4: add dev_ptype_info_get implementation pmd/mlx5: add dev_ptype_info_get implementation pmd/nfp: add dev_ptype_info_get implementation pmd/vmxnet3: add dev_ptype_info_get implementation examples/l3fwd: add option to parse ptype doc/guides/sample_app_ug/l3_forward.rst | 6 +- drivers/net/cxgbe/cxgbe_ethdev.c| 14 drivers/net/e1000/igb_ethdev.c | 30 drivers/net/enic/enic_ethdev.c | 17 + drivers/net/fm10k/fm10k_ethdev.c| 50 + drivers/net/fm10k/fm10k_rxtx.c | 3 + drivers/net/fm10k/fm10k_rxtx_vec.c | 3 + drivers/net/i40e/i40e_ethdev.c | 1 + drivers/net/i40e/i40e_ethdev_vf.c | 1 + drivers/net/i40e/i40e_rxtx.c| 46 +++- drivers/net/i40e/i40e_rxtx.h| 1 + drivers/net/ixgbe/ixgbe_ethdev.c| 38 ++ drivers/net/ixgbe/ixgbe_ethdev.h| 2 + drivers/net/ixgbe/ixgbe_rxtx.c | 4 +- drivers/net/mlx4/mlx4.c | 21 ++ drivers/net/mlx5/mlx5.c | 1 + drivers/net/mlx5/mlx5.h | 1 + drivers/net/mlx5/mlx5_ethdev.c | 20 ++ drivers/net/mlx5/mlx5_rxtx.c| 2 + drivers/net/nfp/nfp_net.c | 19 + drivers/net/vmxnet3/vmxnet3_ethdev.c| 16 + examples/l3fwd/main.c | 122 lib/librte_ether/rte_ethdev.c | 32 + lib/librte_ether/rte_ethdev.h | 23 ++ 24 files changed, 470 insertions(+), 3 deletions(-) -- 2.1.4
[dpdk-dev] [PATCH v3 01/12] ethdev: add API to query packet type filling info
Add a new API rte_eth_dev_get_ptype_info to query whether/what packet
type can be filled by given pmd rx burst function.
Signed-off-by: Jianfeng Tan
---
lib/librte_ether/rte_ethdev.c | 32
lib/librte_ether/rte_ethdev.h | 23 +++
2 files changed, 55 insertions(+)
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index 1257965..b52555b 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -1576,6 +1576,38 @@ rte_eth_dev_info_get(uint8_t port_id, struct
rte_eth_dev_info *dev_info)
dev_info->driver_name = dev->data->drv_name;
}
+int
+rte_eth_dev_get_ptype_info(uint8_t port_id, uint32_t ptype_mask,
+ uint32_t **p_ptypes)
+{
+ int i, j, ret;
+ struct rte_eth_dev *dev;
+ const uint32_t *all_ptypes;
+
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+ dev = &rte_eth_devices[port_id];
+ RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_ptype_info_get, -ENOTSUP);
+ all_ptypes = (*dev->dev_ops->dev_ptype_info_get)(dev);
+
+ if (!all_ptypes)
+ return 0;
+
+ for (i = 0, ret = 0; all_ptypes[i] != RTE_PTYPE_UNKNOWN; ++i)
+ if (all_ptypes[i] & ptype_mask)
+ ret++;
+ if (ret == 0)
+ return 0;
+
+ *p_ptypes = (uint32_t *)malloc(sizeof(uint32_t) * ret);
+ if (*p_ptypes == NULL)
+ return -ENOMEM;
+
+ for (i = 0, j = 0; all_ptypes[i] != RTE_PTYPE_UNKNOWN; ++i)
+ if (all_ptypes[i] & ptype_mask)
+ *p_ptypes[j++] = all_ptypes[i];
+ return ret;
+}
+
void
rte_eth_macaddr_get(uint8_t port_id, struct ether_addr *mac_addr)
{
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 16da821..341e2ff 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -1021,6 +1021,9 @@ typedef void (*eth_dev_infos_get_t)(struct rte_eth_dev
*dev,
struct rte_eth_dev_info *dev_info);
/**< @internal Get specific informations of an Ethernet device. */
+typedef const uint32_t *(*eth_dev_ptype_info_get_t)(struct rte_eth_dev *dev);
+/**< @internal Get ptype info of eth_rx_burst_t. */
+
typedef int (*eth_queue_start_t)(struct rte_eth_dev *dev,
uint16_t queue_id);
/**< @internal Start rx and tx of a queue of an Ethernet device. */
@@ -1347,6 +1350,7 @@ struct eth_dev_ops {
eth_queue_stats_mapping_set_t queue_stats_mapping_set;
/**< Configure per queue stat counter mapping. */
eth_dev_infos_get_tdev_infos_get; /**< Get device info. */
+ eth_dev_ptype_info_get_t dev_ptype_info_get; /** Get ptype info */
mtu_set_t mtu_set; /**< Set MTU. */
vlan_filter_set_t vlan_filter_set; /**< Filter VLAN Setup. */
vlan_tpid_set_tvlan_tpid_set; /**< Outer VLAN TPID
Setup. */
@@ -2268,6 +2272,25 @@ void rte_eth_macaddr_get(uint8_t port_id, struct
ether_addr *mac_addr);
void rte_eth_dev_info_get(uint8_t port_id, struct rte_eth_dev_info *dev_info);
/**
+ * Retrieve the packet type information of an Ethernet device.
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param ptype_mask
+ * A hint of what kind of packet type which the caller is interested in.
+ * @param p_ptypes
+ * A pointer to store address of adequent packet types array. Caller to free.
+ * @return
+ * - (>0) Number of ptypes supported. Need caller to free the array.
+ * - (0 or -ENOTSUP) if PMD does not fill the specified ptype.
+ * - (-ENOMEM) if fail to malloc required memory to store ptypes.
+ * - (-ENODEV) if *port_id* invalid.
+ */
+extern int rte_eth_dev_get_ptype_info(uint8_t port_id,
+ uint32_t ptype_mask,
+ uint32_t **p_ptypes);
+
+/**
* Retrieve the MTU of an Ethernet device.
*
* @param port_id
--
2.1.4
[dpdk-dev] [PATCH v3 02/12] pmd/cxgbe: add dev_ptype_info_get implementation
Signed-off-by: Jianfeng Tan
---
drivers/net/cxgbe/cxgbe_ethdev.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/net/cxgbe/cxgbe_ethdev.c b/drivers/net/cxgbe/cxgbe_ethdev.c
index 97ef152..33bd815 100644
--- a/drivers/net/cxgbe/cxgbe_ethdev.c
+++ b/drivers/net/cxgbe/cxgbe_ethdev.c
@@ -767,6 +767,19 @@ static int cxgbe_flow_ctrl_set(struct rte_eth_dev *eth_dev,
&pi->link_cfg);
}
+static const uint32_t *cxgbe_dev_ptype_info_get(struct rte_eth_dev *eth_dev)
+{
+ static const uint32_t ptypes[] = {
+ RTE_PTYPE_L3_IPV4,
+ RTE_PTYPE_L3_IPV6,
+ RTE_PTYPE_UNKNOWN
+ };
+
+ if (eth_dev->rx_pkt_burst == cxgbe_recv_pkts)
+ return ptypes;
+ return NULL;
+}
+
static struct eth_dev_ops cxgbe_eth_dev_ops = {
.dev_start = cxgbe_dev_start,
.dev_stop = cxgbe_dev_stop,
@@ -777,6 +790,7 @@ static struct eth_dev_ops cxgbe_eth_dev_ops = {
.allmulticast_disable = cxgbe_dev_allmulticast_disable,
.dev_configure = cxgbe_dev_configure,
.dev_infos_get = cxgbe_dev_info_get,
+ .dev_ptype_info_get = cxgbe_dev_ptype_info_get,
.link_update= cxgbe_dev_link_update,
.mtu_set= cxgbe_dev_mtu_set,
.tx_queue_setup = cxgbe_dev_tx_queue_setup,
--
2.1.4
[dpdk-dev] [PATCH v3 03/12] pmd/e1000: add dev_ptype_info_get implementation
Signed-off-by: Jianfeng Tan
---
drivers/net/e1000/igb_ethdev.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
index 4ed5e95..b3a3ee6 100644
--- a/drivers/net/e1000/igb_ethdev.c
+++ b/drivers/net/e1000/igb_ethdev.c
@@ -103,6 +103,7 @@ static void eth_igb_stats_reset(struct rte_eth_dev *dev);
static void eth_igb_xstats_reset(struct rte_eth_dev *dev);
static void eth_igb_infos_get(struct rte_eth_dev *dev,
struct rte_eth_dev_info *dev_info);
+static const uint32_t *eth_igb_ptype_info_get(struct rte_eth_dev *dev);
static void eth_igbvf_infos_get(struct rte_eth_dev *dev,
struct rte_eth_dev_info *dev_info);
static int eth_igb_flow_ctrl_get(struct rte_eth_dev *dev,
@@ -319,6 +320,7 @@ static const struct eth_dev_ops eth_igb_ops = {
.stats_reset = eth_igb_stats_reset,
.xstats_reset = eth_igb_xstats_reset,
.dev_infos_get= eth_igb_infos_get,
+ .dev_ptype_info_get = eth_igb_ptype_info_get,
.mtu_set = eth_igb_mtu_set,
.vlan_filter_set = eth_igb_vlan_filter_set,
.vlan_tpid_set= eth_igb_vlan_tpid_set,
@@ -376,6 +378,7 @@ static const struct eth_dev_ops igbvf_eth_dev_ops = {
.xstats_reset = eth_igbvf_stats_reset,
.vlan_filter_set = igbvf_vlan_filter_set,
.dev_infos_get= eth_igbvf_infos_get,
+ .dev_ptype_info_get = eth_igb_ptype_info_get,
.rx_queue_setup = eth_igb_rx_queue_setup,
.rx_queue_release = eth_igb_rx_queue_release,
.tx_queue_setup = eth_igb_tx_queue_setup,
@@ -1910,6 +1913,33 @@ eth_igb_infos_get(struct rte_eth_dev *dev, struct
rte_eth_dev_info *dev_info)
dev_info->tx_desc_lim = tx_desc_lim;
}
+static const uint32_t *
+eth_igb_ptype_info_get(struct rte_eth_dev *dev)
+{
+ static const uint32_t ptypes[] = {
+ /* refers to igb_rxd_pkt_info_to_pkt_type() */
+ RTE_PTYPE_L2_ETHER,
+ RTE_PTYPE_L3_IPV4,
+ RTE_PTYPE_L3_IPV4_EXT,
+ RTE_PTYPE_L3_IPV6,
+ RTE_PTYPE_L3_IPV6_EXT,
+ RTE_PTYPE_L4_TCP,
+ RTE_PTYPE_L4_UDP,
+ RTE_PTYPE_L4_SCTP,
+ RTE_PTYPE_TUNNEL_IP,
+ RTE_PTYPE_INNER_L3_IPV6,
+ RTE_PTYPE_INNER_L3_IPV6_EXT,
+ RTE_PTYPE_INNER_L4_TCP,
+ RTE_PTYPE_INNER_L4_UDP,
+ RTE_PTYPE_UNKNOWN
+ };
+
+ if (dev->rx_pkt_burst == eth_igb_recv_pkts ||
+ dev->rx_pkt_burst == eth_igb_recv_scattered_pkts)
+ return ptypes;
+ return NULL;
+}
+
static void
eth_igbvf_infos_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
{
--
2.1.4
[dpdk-dev] [PATCH v3 04/12] pmd/enic: add dev_ptype_info_get implementation
Signed-off-by: Jianfeng Tan
---
drivers/net/enic/enic_ethdev.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/net/enic/enic_ethdev.c b/drivers/net/enic/enic_ethdev.c
index 2a88043..fbeab6f 100644
--- a/drivers/net/enic/enic_ethdev.c
+++ b/drivers/net/enic/enic_ethdev.c
@@ -54,6 +54,9 @@
#define ENICPMD_FUNC_TRACE() (void)0
#endif
+static uint16_t enicpmd_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts,
+ uint16_t nb_pkts);
+
/*
* The set of PCI devices this driver supports
*/
@@ -431,6 +434,19 @@ static void enicpmd_dev_info_get(struct rte_eth_dev
*eth_dev,
DEV_TX_OFFLOAD_TCP_CKSUM;
}
+static const uint32_t *enicpmd_dev_ptype_info_get(struct rte_eth_dev *dev)
+{
+ static const uint32_t ptypes[] = {
+ RTE_PTYPE_L3_IPV4,
+ RTE_PTYPE_L3_IPV6,
+ RTE_PTYPE_UNKNOWN
+ };
+
+ if (dev->rx_pkt_burst == enicpmd_recv_pkts)
+ return ptypes;
+ return NULL;
+}
+
static void enicpmd_dev_promiscuous_enable(struct rte_eth_dev *eth_dev)
{
struct enic *enic = pmd_priv(eth_dev);
@@ -566,6 +582,7 @@ static const struct eth_dev_ops enicpmd_eth_dev_ops = {
.stats_reset = enicpmd_dev_stats_reset,
.queue_stats_mapping_set = NULL,
.dev_infos_get= enicpmd_dev_info_get,
+ .dev_ptype_info_get = enicpmd_dev_ptype_info_get,
.mtu_set = NULL,
.vlan_filter_set = enicpmd_vlan_filter_set,
.vlan_tpid_set= NULL,
--
2.1.4
[dpdk-dev] [PATCH v3 05/12] pmd/fm10k: add dev_ptype_info_get implementation
Signed-off-by: Jianfeng Tan
---
drivers/net/fm10k/fm10k_ethdev.c | 50 ++
drivers/net/fm10k/fm10k_rxtx.c | 3 +++
drivers/net/fm10k/fm10k_rxtx_vec.c | 3 +++
3 files changed, 56 insertions(+)
diff --git a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_ethdev.c
index 421266b..429cbdd 100644
--- a/drivers/net/fm10k/fm10k_ethdev.c
+++ b/drivers/net/fm10k/fm10k_ethdev.c
@@ -1335,6 +1335,55 @@ fm10k_dev_infos_get(struct rte_eth_dev *dev,
};
}
+#ifdef RTE_LIBRTE_FM10K_RX_OLFLAGS_ENABLE
+static const uint32_t *
+fm10k_dev_ptype_info_get(struct rte_eth_dev *dev)
+{
+ if (dev->rx_pkt_burst == fm10k_recv_pkts ||
+ dev->rx_pkt_burst == fm10k_recv_scattered_pkts) {
+ static uint32_t ptypes[] = {
+ /* refers to rx_desc_to_ol_flags() */
+ RTE_PTYPE_L2_ETHER,
+ RTE_PTYPE_L3_IPV4,
+ RTE_PTYPE_L3_IPV4_EXT,
+ RTE_PTYPE_L3_IPV6,
+ RTE_PTYPE_L3_IPV6_EXT,
+ RTE_PTYPE_L4_TCP,
+ RTE_PTYPE_L4_UDP,
+ RTE_PTYPE_UNKNOWN
+ };
+
+ return ptypes;
+ } else if (dev->rx_pkt_burst == fm10k_recv_pkts_vec ||
+ dev->rx_pkt_burst == fm10k_recv_scattered_pkts_vec) {
+ static uint32_t ptypes_vec[] = {
+ /* refers to fm10k_desc_to_pktype_v() */
+ RTE_PTYPE_L3_IPV4,
+ RTE_PTYPE_L3_IPV4_EXT,
+ RTE_PTYPE_L3_IPV6,
+ RTE_PTYPE_L3_IPV6_EXT,
+ RTE_PTYPE_L4_TCP,
+ RTE_PTYPE_L4_UDP,
+ RTE_PTYPE_TUNNEL_GENEVE,
+ RTE_PTYPE_TUNNEL_NVGRE,
+ RTE_PTYPE_TUNNEL_VXLAN,
+ RTE_PTYPE_TUNNEL_GRE,
+ RTE_PTYPE_UNKNOWN
+ };
+
+ return ptypes_vec;
+ }
+
+ return NULL;
+}
+#else
+static const uint32_t *
+fm10k_dev_ptype_info_get(struct rte_eth_dev *dev __rte_unused)
+{
+ return NULL;
+}
+#endif
+
static int
fm10k_vlan_filter_set(struct rte_eth_dev *dev, uint16_t vlan_id, int on)
{
@@ -2423,6 +2472,7 @@ static const struct eth_dev_ops fm10k_eth_dev_ops = {
.xstats_reset = fm10k_stats_reset,
.link_update= fm10k_link_update,
.dev_infos_get = fm10k_dev_infos_get,
+ .dev_ptype_info_get = fm10k_dev_ptype_info_get,
.vlan_filter_set= fm10k_vlan_filter_set,
.vlan_offload_set = fm10k_vlan_offload_set,
.mac_addr_add = fm10k_macaddr_add,
diff --git a/drivers/net/fm10k/fm10k_rxtx.c b/drivers/net/fm10k/fm10k_rxtx.c
index e958865..cbe0111 100644
--- a/drivers/net/fm10k/fm10k_rxtx.c
+++ b/drivers/net/fm10k/fm10k_rxtx.c
@@ -65,6 +65,9 @@ static inline void dump_rxd(union fm10k_rx_desc *rxd)
}
#endif
+/* @note: When this function is changed, make corresponding change to
+ * fm10k_dev_ptype_info_get()
+ */
static inline void
rx_desc_to_ol_flags(struct rte_mbuf *m, const union fm10k_rx_desc *d)
{
diff --git a/drivers/net/fm10k/fm10k_rxtx_vec.c
b/drivers/net/fm10k/fm10k_rxtx_vec.c
index 2a57eef..f347641 100644
--- a/drivers/net/fm10k/fm10k_rxtx_vec.c
+++ b/drivers/net/fm10k/fm10k_rxtx_vec.c
@@ -109,6 +109,9 @@ fm10k_desc_to_olflags_v(__m128i descs[4], struct rte_mbuf
**rx_pkts)
rx_pkts[3]->ol_flags = vol.e[3];
}
+/* @note: When this function is changed, make corresponding change to
+ * fm10k_dev_ptype_info_get().
+ */
static inline void
fm10k_desc_to_pktype_v(__m128i descs[4], struct rte_mbuf **rx_pkts)
{
--
2.1.4
[dpdk-dev] [PATCH v3 06/12] pmd/i40e: add dev_ptype_info_get implementation
Signed-off-by: Jianfeng Tan
---
drivers/net/i40e/i40e_ethdev.c| 1 +
drivers/net/i40e/i40e_ethdev_vf.c | 1 +
drivers/net/i40e/i40e_rxtx.c | 46 ++-
drivers/net/i40e/i40e_rxtx.h | 1 +
4 files changed, 48 insertions(+), 1 deletion(-)
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index ef24122..81849fa 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -439,6 +439,7 @@ static const struct eth_dev_ops i40e_eth_dev_ops = {
.xstats_reset = i40e_dev_stats_reset,
.queue_stats_mapping_set = i40e_dev_queue_stats_mapping_set,
.dev_infos_get= i40e_dev_info_get,
+ .dev_ptype_info_get = i40e_dev_ptype_info_get,
.vlan_filter_set = i40e_vlan_filter_set,
.vlan_tpid_set= i40e_vlan_tpid_set,
.vlan_offload_set = i40e_vlan_offload_set,
diff --git a/drivers/net/i40e/i40e_ethdev_vf.c
b/drivers/net/i40e/i40e_ethdev_vf.c
index 13c5b3d..afd436e 100644
--- a/drivers/net/i40e/i40e_ethdev_vf.c
+++ b/drivers/net/i40e/i40e_ethdev_vf.c
@@ -196,6 +196,7 @@ static const struct eth_dev_ops i40evf_eth_dev_ops = {
.xstats_reset = i40evf_dev_xstats_reset,
.dev_close= i40evf_dev_close,
.dev_infos_get= i40evf_dev_info_get,
+ .dev_ptype_info_get = i40e_dev_ptype_info_get,
.vlan_filter_set = i40evf_vlan_filter_set,
.vlan_offload_set = i40evf_vlan_offload_set,
.vlan_pvid_set= i40evf_vlan_pvid_set,
diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
index 40cffc1..1a952df 100644
--- a/drivers/net/i40e/i40e_rxtx.c
+++ b/drivers/net/i40e/i40e_rxtx.c
@@ -194,7 +194,10 @@ i40e_get_iee15888_flags(struct rte_mbuf *mb, uint64_t
qword)
}
#endif
-/* For each value it means, datasheet of hardware can tell more details */
+/* For each value it means, datasheet of hardware can tell more details
+ *
+ * @note: fix i40e_dev_ptype_info_get() if any change here.
+ */
static inline uint32_t
i40e_rxd_pkt_type_mapping(uint8_t ptype)
{
@@ -2093,6 +2096,47 @@ i40e_dev_tx_queue_stop(struct rte_eth_dev *dev, uint16_t
tx_queue_id)
return 0;
}
+const uint32_t *
+i40e_dev_ptype_info_get(struct rte_eth_dev *dev)
+{
+ static const uint32_t ptypes[] = {
+ /* refers to i40e_rxd_pkt_type_mapping() */
+ RTE_PTYPE_L2_ETHER,
+ RTE_PTYPE_L2_ETHER_TIMESYNC,
+ RTE_PTYPE_L2_ETHER_LLDP,
+ RTE_PTYPE_L2_ETHER_ARP,
+ RTE_PTYPE_L3_IPV4_EXT_UNKNOWN,
+ RTE_PTYPE_L3_IPV6_EXT_UNKNOWN,
+ RTE_PTYPE_L4_FRAG,
+ RTE_PTYPE_L4_ICMP,
+ RTE_PTYPE_L4_NONFRAG,
+ RTE_PTYPE_L4_SCTP,
+ RTE_PTYPE_L4_TCP,
+ RTE_PTYPE_L4_UDP,
+ RTE_PTYPE_TUNNEL_GRENAT,
+ RTE_PTYPE_TUNNEL_IP,
+ RTE_PTYPE_INNER_L2_ETHER,
+ RTE_PTYPE_INNER_L2_ETHER_VLAN,
+ RTE_PTYPE_INNER_L3_IPV4_EXT_UNKNOWN,
+ RTE_PTYPE_INNER_L3_IPV6_EXT_UNKNOWN,
+ RTE_PTYPE_INNER_L4_FRAG,
+ RTE_PTYPE_INNER_L4_ICMP,
+ RTE_PTYPE_INNER_L4_NONFRAG,
+ RTE_PTYPE_INNER_L4_SCTP,
+ RTE_PTYPE_INNER_L4_TCP,
+ RTE_PTYPE_INNER_L4_UDP,
+ RTE_PTYPE_UNKNOWN
+ };
+
+ if (dev->rx_pkt_burst == i40e_recv_pkts ||
+#ifdef RTE_LIBRTE_I40E_RX_ALLOW_BULK_ALLOC
+ dev->rx_pkt_burst == i40e_recv_pkts_bulk_alloc ||
+#endif
+ dev->rx_pkt_burst == i40e_recv_scattered_pkts)
+ return ptypes;
+ return NULL;
+}
+
int
i40e_dev_rx_queue_setup(struct rte_eth_dev *dev,
uint16_t queue_idx,
diff --git a/drivers/net/i40e/i40e_rxtx.h b/drivers/net/i40e/i40e_rxtx.h
index 5c2f5c2..3a59d81 100644
--- a/drivers/net/i40e/i40e_rxtx.h
+++ b/drivers/net/i40e/i40e_rxtx.h
@@ -200,6 +200,7 @@ int i40e_dev_rx_queue_start(struct rte_eth_dev *dev,
uint16_t rx_queue_id);
int i40e_dev_rx_queue_stop(struct rte_eth_dev *dev, uint16_t rx_queue_id);
int i40e_dev_tx_queue_start(struct rte_eth_dev *dev, uint16_t tx_queue_id);
int i40e_dev_tx_queue_stop(struct rte_eth_dev *dev, uint16_t tx_queue_id);
+const uint32_t *i40e_dev_ptype_info_get(struct rte_eth_dev *dev);
int i40e_dev_rx_queue_setup(struct rte_eth_dev *dev,
uint16_t queue_idx,
uint16_t nb_desc,
--
2.1.4
[dpdk-dev] [PATCH v3 07/12] pmd/ixgbe: add dev_ptype_info_get implementation
Signed-off-by: Jianfeng Tan
---
drivers/net/ixgbe/ixgbe_ethdev.c | 38 ++
drivers/net/ixgbe/ixgbe_ethdev.h | 2 ++
drivers/net/ixgbe/ixgbe_rxtx.c | 4 +++-
3 files changed, 43 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 3e6fe86..605d958 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -166,6 +166,7 @@ static int ixgbe_dev_queue_stats_mapping_set(struct
rte_eth_dev *eth_dev,
uint8_t is_rx);
static void ixgbe_dev_info_get(struct rte_eth_dev *dev,
struct rte_eth_dev_info *dev_info);
+static const uint32_t *ixgbe_dev_ptype_info_get(struct rte_eth_dev *dev);
static void ixgbevf_dev_info_get(struct rte_eth_dev *dev,
struct rte_eth_dev_info *dev_info);
static int ixgbe_dev_mtu_set(struct rte_eth_dev *dev, uint16_t mtu);
@@ -428,6 +429,7 @@ static const struct eth_dev_ops ixgbe_eth_dev_ops = {
.xstats_reset = ixgbe_dev_xstats_reset,
.queue_stats_mapping_set = ixgbe_dev_queue_stats_mapping_set,
.dev_infos_get= ixgbe_dev_info_get,
+ .dev_ptype_info_get = ixgbe_dev_ptype_info_get,
.mtu_set = ixgbe_dev_mtu_set,
.vlan_filter_set = ixgbe_vlan_filter_set,
.vlan_tpid_set= ixgbe_vlan_tpid_set,
@@ -512,6 +514,7 @@ static const struct eth_dev_ops ixgbevf_eth_dev_ops = {
.xstats_reset = ixgbevf_dev_stats_reset,
.dev_close= ixgbevf_dev_close,
.dev_infos_get= ixgbevf_dev_info_get,
+ .dev_ptype_info_get = ixgbe_dev_ptype_info_get,
.mtu_set = ixgbevf_dev_set_mtu,
.vlan_filter_set = ixgbevf_vlan_filter_set,
.vlan_strip_queue_set = ixgbevf_vlan_strip_queue_set,
@@ -2829,6 +2832,41 @@ ixgbe_dev_info_get(struct rte_eth_dev *dev, struct
rte_eth_dev_info *dev_info)
dev_info->flow_type_rss_offloads = IXGBE_RSS_OFFLOAD_ALL;
}
+static const uint32_t *
+ixgbe_dev_ptype_info_get(struct rte_eth_dev *dev)
+{
+ static const uint32_t ptypes[] = {
+ /* For non-vec functions,
+* refers to ixgbe_rxd_pkt_info_to_pkt_type();
+* for vec functions,
+* refers to _recv_raw_pkts_vec().
+*/
+ RTE_PTYPE_L2_ETHER,
+ RTE_PTYPE_L3_IPV4,
+ RTE_PTYPE_L3_IPV4_EXT,
+ RTE_PTYPE_L3_IPV6,
+ RTE_PTYPE_L3_IPV6_EXT,
+ RTE_PTYPE_L4_SCTP,
+ RTE_PTYPE_L4_TCP,
+ RTE_PTYPE_L4_UDP,
+ RTE_PTYPE_TUNNEL_IP,
+ RTE_PTYPE_INNER_L3_IPV6,
+ RTE_PTYPE_INNER_L3_IPV6_EXT,
+ RTE_PTYPE_INNER_L4_TCP,
+ RTE_PTYPE_INNER_L4_UDP,
+ RTE_PTYPE_UNKNOWN
+ };
+
+ if (dev->rx_pkt_burst == ixgbe_recv_pkts ||
+ dev->rx_pkt_burst == ixgbe_recv_pkts_lro_single_alloc ||
+ dev->rx_pkt_burst == ixgbe_recv_pkts_lro_bulk_alloc ||
+ dev->rx_pkt_burst == ixgbe_recv_pkts_bulk_alloc ||
+ dev->rx_pkt_burst == ixgbe_recv_pkts_vec ||
+ dev->rx_pkt_burst == ixgbe_recv_scattered_pkts_vec)
+ return ptypes;
+ return NULL;
+}
+
static void
ixgbevf_dev_info_get(struct rte_eth_dev *dev,
struct rte_eth_dev_info *dev_info)
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.h b/drivers/net/ixgbe/ixgbe_ethdev.h
index d26771a..b07d3da 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.h
+++ b/drivers/net/ixgbe/ixgbe_ethdev.h
@@ -379,6 +379,8 @@ void ixgbevf_dev_rxtx_start(struct rte_eth_dev *dev);
uint16_t ixgbe_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts,
uint16_t nb_pkts);
+uint16_t ixgbe_recv_pkts_bulk_alloc(void *rx_queue, struct rte_mbuf **rx_pkts,
+ uint16_t nb_pkts);
uint16_t ixgbe_recv_pkts_lro_single_alloc(void *rx_queue,
struct rte_mbuf **rx_pkts, uint16_t nb_pkts);
uint16_t ixgbe_recv_pkts_lro_bulk_alloc(void *rx_queue,
diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c b/drivers/net/ixgbe/ixgbe_rxtx.c
index e95e6b7..17851cc 100644
--- a/drivers/net/ixgbe/ixgbe_rxtx.c
+++ b/drivers/net/ixgbe/ixgbe_rxtx.c
@@ -899,6 +899,8 @@ end_of_tx:
#define IXGBE_PACKET_TYPE_MAX 0X80
#define IXGBE_PACKET_TYPE_MASK 0X7F
#define IXGBE_PACKET_TYPE_SHIFT 0X04
+
+/* @note: fix ixgbe_dev_ptype_info_get() if any change here. */
static inline uint32_t
ixgbe_rxd_pkt_info_to_pkt_type(uint16_t pkt_info)
{
@@ -1247,7 +1249,7 @@ rx_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts,
}
/* split requests into chunks of size RTE_PMD_IXGBE_RX_MAX_BURST */
-static uint16_t
+uint16_t
ixgbe_recv_pkts_bulk_alloc(void *rx_queue, struct rte_mbuf **rx_pkts,
uint16_t nb_pkts)
[dpdk-dev] [PATCH v3 08/12] pmd/mlx4: add dev_ptype_info_get implementation
Signed-off-by: Jianfeng Tan
---
drivers/net/mlx4/mlx4.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
index ee00151..85fdebf 100644
--- a/drivers/net/mlx4/mlx4.c
+++ b/drivers/net/mlx4/mlx4.c
@@ -2835,6 +2835,8 @@ rxq_cleanup(struct rxq *rxq)
* @param flags
* RX completion flags returned by poll_length_flags().
*
+ * @note: fix mlx4_dev_ptype_info_get() if any change here.
+ *
* @return
* Packet type for struct rte_mbuf.
*/
@@ -4267,6 +4269,24 @@ mlx4_dev_infos_get(struct rte_eth_dev *dev, struct
rte_eth_dev_info *info)
priv_unlock(priv);
}
+static uint32_t *
+mlx4_dev_ptype_info_get(struct rte_eth_dev *dev)
+{
+ static const uint32_t ptypes[] = {
+ /* refers to rxq_cq_to_pkt_type() */
+ RTE_PTYPE_L3_IPV4,
+ RTE_PTYPE_L3_IPV6,
+ RTE_PTYPE_INNER_L3_IPV4,
+ RTE_PTYPE_INNER_L3_IPV6,
+ RTE_PTYPE_UNKNOWN
+ };
+
+ if (dev->rx_pkt_burst == mlx4_rx_burst ||
+ dev->rx_pkt_burst == mlx4_rx_burst_sp)
+ return ptypes;
+ return NULL;
+}
+
/**
* DPDK callback to get device statistics.
*
@@ -4988,6 +5008,7 @@ static const struct eth_dev_ops mlx4_dev_ops = {
.stats_reset = mlx4_stats_reset,
.queue_stats_mapping_set = NULL,
.dev_infos_get = mlx4_dev_infos_get,
+ .dev_ptypes_info_get = mlx4_dev_ptype_info_get,
.vlan_filter_set = mlx4_vlan_filter_set,
.vlan_tpid_set = NULL,
.vlan_strip_queue_set = NULL,
--
2.1.4
[dpdk-dev] [PATCH v3 09/12] pmd/mlx5: add dev_ptype_info_get implementation
Signed-off-by: Jianfeng Tan
---
drivers/net/mlx4/mlx4.c| 2 +-
drivers/net/mlx5/mlx5.c| 1 +
drivers/net/mlx5/mlx5.h| 1 +
drivers/net/mlx5/mlx5_ethdev.c | 20
drivers/net/mlx5/mlx5_rxtx.c | 2 ++
5 files changed, 25 insertions(+), 1 deletion(-)
diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
index 85fdebf..58f4e1a 100644
--- a/drivers/net/mlx4/mlx4.c
+++ b/drivers/net/mlx4/mlx4.c
@@ -4269,7 +4269,7 @@ mlx4_dev_infos_get(struct rte_eth_dev *dev, struct
rte_eth_dev_info *info)
priv_unlock(priv);
}
-static uint32_t *
+static const uint32_t *
mlx4_dev_ptype_info_get(struct rte_eth_dev *dev)
{
static const uint32_t ptypes[] = {
diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
index 821ee0f..e18b1e9 100644
--- a/drivers/net/mlx5/mlx5.c
+++ b/drivers/net/mlx5/mlx5.c
@@ -153,6 +153,7 @@ static const struct eth_dev_ops mlx5_dev_ops = {
.stats_get = mlx5_stats_get,
.stats_reset = mlx5_stats_reset,
.dev_infos_get = mlx5_dev_infos_get,
+ .dev_ptype_info_get = mlx5_dev_ptype_info_get,
.vlan_filter_set = mlx5_vlan_filter_set,
.rx_queue_setup = mlx5_rx_queue_setup,
.tx_queue_setup = mlx5_tx_queue_setup,
diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h
index b84d31d..196435d 100644
--- a/drivers/net/mlx5/mlx5.h
+++ b/drivers/net/mlx5/mlx5.h
@@ -156,6 +156,7 @@ int priv_get_mtu(struct priv *, uint16_t *);
int priv_set_flags(struct priv *, unsigned int, unsigned int);
int mlx5_dev_configure(struct rte_eth_dev *);
void mlx5_dev_infos_get(struct rte_eth_dev *, struct rte_eth_dev_info *);
+const uint32_t *mlx5_dev_ptype_info_get(struct rte_eth_dev *dev);
int mlx5_link_update(struct rte_eth_dev *, int);
int mlx5_dev_set_mtu(struct rte_eth_dev *, uint16_t);
int mlx5_dev_get_flow_ctrl(struct rte_eth_dev *, struct rte_eth_fc_conf *);
diff --git a/drivers/net/mlx5/mlx5_ethdev.c b/drivers/net/mlx5/mlx5_ethdev.c
index 1159fa3..406f8dc 100644
--- a/drivers/net/mlx5/mlx5_ethdev.c
+++ b/drivers/net/mlx5/mlx5_ethdev.c
@@ -526,6 +526,26 @@ mlx5_dev_infos_get(struct rte_eth_dev *dev, struct
rte_eth_dev_info *info)
priv_unlock(priv);
}
+const uint32_t *
+mlx5_dev_ptype_info_get(struct rte_eth_dev *dev)
+{
+ static const uint32_t ptypes[] = {
+ /* refers to rxq_cq_to_pkt_type() */
+ RTE_PTYPE_L3_IPV4,
+ RTE_PTYPE_L3_IPV6,
+ RTE_PTYPE_INNER_L3_IPV4,
+ RTE_PTYPE_INNER_L3_IPV6,
+ RTE_PTYPE_UNKNOWN
+
+ };
+
+ if (dev->rx_pkt_burst == mlx5_rx_burst ||
+ dev->rx_pkt_burst == mlx5_rx_burst_sp)
+ return ptypes;
+ return NULL;
+
+}
+
/**
* DPDK callback to retrieve physical link information (unlocked version).
*
diff --git a/drivers/net/mlx5/mlx5_rxtx.c b/drivers/net/mlx5/mlx5_rxtx.c
index fa5e648..79bdf8d 100644
--- a/drivers/net/mlx5/mlx5_rxtx.c
+++ b/drivers/net/mlx5/mlx5_rxtx.c
@@ -603,6 +603,8 @@ stop:
* @param flags
* RX completion flags returned by poll_length_flags().
*
+ * @note: fix mlx5_dev_ptype_info_get() if any change here.
+ *
* @return
* Packet type for struct rte_mbuf.
*/
--
2.1.4
[dpdk-dev] [PATCH v3 10/12] pmd/nfp: add dev_ptype_info_get implementation
Signed-off-by: Jianfeng Tan
---
drivers/net/nfp/nfp_net.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/net/nfp/nfp_net.c b/drivers/net/nfp/nfp_net.c
index fd4dd39..5894a9d 100644
--- a/drivers/net/nfp/nfp_net.c
+++ b/drivers/net/nfp/nfp_net.c
@@ -1073,6 +1073,24 @@ nfp_net_infos_get(struct rte_eth_dev *dev, struct
rte_eth_dev_info *dev_info)
dev_info->hash_key_size = NFP_NET_CFG_RSS_KEY_SZ;
}
+static const uint32_t *
+nfp_net_ptype_info_get(struct rte_eth_dev *dev)
+{
+ static const uint32_t ptypes[] = {
+ /* refers to nfp_net_set_hash() */
+ RTE_PTYPE_INNER_L3_IPV4,
+ RTE_PTYPE_INNER_L3_IPV6,
+ RTE_PTYPE_INNER_L3_IPV6_EXT,
+ RTE_PTYPE_INNER_L4_MASK,
+ RTE_PTYPE_UNKNOWN
+ };
+
+
+ if (dev->rx_pkt_burst == nfp_net_recv_pkts)
+ return ptypes;
+ return num;
+}
+
static uint32_t
nfp_net_rx_queue_count(struct rte_eth_dev *dev, uint16_t queue_idx)
{
@@ -2292,6 +2310,7 @@ static struct eth_dev_ops nfp_net_eth_dev_ops = {
.stats_get = nfp_net_stats_get,
.stats_reset= nfp_net_stats_reset,
.dev_infos_get = nfp_net_infos_get,
+ .dev_ptype_info_get = nfp_net_ptype_info_get,
.mtu_set= nfp_net_dev_mtu_set,
.vlan_offload_set = nfp_net_vlan_offload_set,
.reta_update= nfp_net_reta_update,
--
2.1.4
[dpdk-dev] [PATCH v3 11/12] pmd/vmxnet3: add dev_ptype_info_get implementation
Signed-off-by: Jianfeng Tan
---
drivers/net/vmxnet3/vmxnet3_ethdev.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/net/vmxnet3/vmxnet3_ethdev.c
b/drivers/net/vmxnet3/vmxnet3_ethdev.c
index c363bf6..ac120a1 100644
--- a/drivers/net/vmxnet3/vmxnet3_ethdev.c
+++ b/drivers/net/vmxnet3/vmxnet3_ethdev.c
@@ -86,6 +86,7 @@ static void vmxnet3_dev_stats_get(struct rte_eth_dev *dev,
struct rte_eth_stats *stats);
static void vmxnet3_dev_info_get(struct rte_eth_dev *dev,
struct rte_eth_dev_info *dev_info);
+static const uint32_t *vmxnet3_dev_ptype_info_get(struct rte_eth_dev *dev);
static int vmxnet3_dev_vlan_filter_set(struct rte_eth_dev *dev,
uint16_t vid, int on);
static void vmxnet3_dev_vlan_offload_set(struct rte_eth_dev *dev, int mask);
@@ -118,6 +119,7 @@ static const struct eth_dev_ops vmxnet3_eth_dev_ops = {
.link_update = vmxnet3_dev_link_update,
.stats_get= vmxnet3_dev_stats_get,
.dev_infos_get= vmxnet3_dev_info_get,
+ .dev_ptype_info_get = vmxnet3_dev_ptype_info_get,
.vlan_filter_set = vmxnet3_dev_vlan_filter_set,
.vlan_offload_set = vmxnet3_dev_vlan_offload_set,
.rx_queue_setup = vmxnet3_dev_rx_queue_setup,
@@ -718,6 +720,20 @@ vmxnet3_dev_info_get(__attribute__((unused))struct
rte_eth_dev *dev, struct rte_
};
}
+static const uint32_t *
+vmxnet3_dev_ptype_info_get(struct rte_eth_dev *dev)
+{
+ static const uint32_t ptypes[] = {
+ RTE_PTYPE_L3_IPV4_EXT,
+ RTE_PTYPE_L3_IPV4,
+ RTE_PTYPE_UNKNOWN
+ };
+
+ if (dev->rx_pkt_burst == vmxnet3_recv_pkts)
+ return ptypes;
+ return NULL;
+}
+
/* return 0 means link status changed, -1 means not changed */
static int
vmxnet3_dev_link_update(struct rte_eth_dev *dev, __attribute__((unused)) int
wait_to_complete)
--
2.1.4
[dpdk-dev] [PATCH v3 12/12] examples/l3fwd: add option to parse ptype
As a example to use ptype info, l3fwd needs firstly to use
rte_eth_dev_get_ptype_info() API to check if device and/or PMD driver will
parse and fill the needed packet type; if not, use the newly added option,
--parse-ptype, to analyze it in the callback softly.
Under the mode of EXACT_MATCH, ip packets with extensions or ip packets
which are neither tcp nor udp cannot work well because it needs the 5
tuples to caculate hash.
Signed-off-by: Jianfeng Tan
---
doc/guides/sample_app_ug/l3_forward.rst | 6 +-
examples/l3fwd/main.c | 122
2 files changed, 127 insertions(+), 1 deletion(-)
diff --git a/doc/guides/sample_app_ug/l3_forward.rst
b/doc/guides/sample_app_ug/l3_forward.rst
index 4ce734b..e0c22e3 100644
--- a/doc/guides/sample_app_ug/l3_forward.rst
+++ b/doc/guides/sample_app_ug/l3_forward.rst
@@ -93,7 +93,7 @@ The application has a number of command line options:
.. code-block:: console
-./build/l3fwd [EAL options] -- -p PORTMASK [-P]
--config(port,queue,lcore)[,(port,queue,lcore)] [--enable-jumbo [--max-pkt-len
PKTLEN]] [--no-numa][--hash-entry-num][--ipv6]
+./build/l3fwd [EAL options] -- -p PORTMASK [-P]
--config(port,queue,lcore)[,(port,queue,lcore)] [--enable-jumbo [--max-pkt-len
PKTLEN]] [--no-numa][--hash-entry-num][--ipv6] [--parse-ptype]
where,
@@ -114,6 +114,8 @@ where,
* --ipv6: optional, set it if running ipv6 packets
+* --parse-ptype: optional, set it if use software way to analyze packet type
+
For example, consider a dual processor socket platform where cores 0-7 and
16-23 appear on socket 0, while cores 8-15 and 24-31 appear on socket 1.
Let's say that the programmer wants to use memory from both NUMA nodes, the
platform has only two ports, one connected to each NUMA node,
and the programmer wants to use two cores from each processor socket to do the
packet processing.
@@ -334,6 +336,8 @@ The key code snippet of simple_ipv4_fwd_4pkts() is shown
below:
The simple_ipv6_fwd_4pkts() function is similar to the simple_ipv4_fwd_4pkts()
function.
+Known issue: IP packets with extensions or IP packets which are not TCP/UDP
cannot work well with this mode.
+
Packet Forwarding for LPM-based Lookups
~~~
diff --git a/examples/l3fwd/main.c b/examples/l3fwd/main.c
index 410f72d..3c43a90 100644
--- a/examples/l3fwd/main.c
+++ b/examples/l3fwd/main.c
@@ -178,6 +178,8 @@ static __m128i val_eth[RTE_MAX_ETHPORTS];
static uint32_t enabled_port_mask = 0;
static int promiscuous_on = 0; /**< Ports set in promiscuous mode off by
default. */
static int numa_on = 1; /**< NUMA is enabled by default. */
+static int parse_ptype; /**< Parse packet type using rx callback, and */
+ /**< disabled by default */
#if (APP_LOOKUP_METHOD == APP_LOOKUP_EXACT_MATCH)
static int ipv6 = 0; /**< ipv6 is false by default. */
@@ -2029,6 +2031,7 @@ parse_eth_dest(const char *optarg)
#define CMD_LINE_OPT_IPV6 "ipv6"
#define CMD_LINE_OPT_ENABLE_JUMBO "enable-jumbo"
#define CMD_LINE_OPT_HASH_ENTRY_NUM "hash-entry-num"
+#define CMD_LINE_OPT_PARSE_PTYPE "parse-ptype"
/* Parse the argument given in the command line of the application */
static int
@@ -2045,6 +2048,7 @@ parse_args(int argc, char **argv)
{CMD_LINE_OPT_IPV6, 0, 0, 0},
{CMD_LINE_OPT_ENABLE_JUMBO, 0, 0, 0},
{CMD_LINE_OPT_HASH_ENTRY_NUM, 1, 0, 0},
+ {CMD_LINE_OPT_PARSE_PTYPE, 0, 0, 0},
{NULL, 0, 0, 0}
};
@@ -2132,6 +2136,13 @@ parse_args(int argc, char **argv)
}
}
#endif
+ if (!strncmp(lgopts[option_index].name,
+CMD_LINE_OPT_PARSE_PTYPE,
+sizeof(CMD_LINE_OPT_PARSE_PTYPE))) {
+ printf("soft parse-ptype is enabled\n");
+ parse_ptype = 1;
+ }
+
break;
default:
@@ -2580,6 +2591,105 @@ signal_handler(int signum)
}
}
+static int
+check_packet_type_ok(int portid)
+{
+ int i, ret;
+ uint32_t *ptypes;
+ int ptype_l3_ipv4 = 0, ptype_l3_ipv6 = 0;
+
+ ret = rte_eth_dev_get_ptype_info(portid, RTE_PTYPE_L3_MASK, &ptypes);
+ if (ret <= 0)
+ return 0;
+
+ for (i = 0; i < ret; ++i) {
+ if (ptypes[i] & RTE_PTYPE_L3_IPV4)
+ ptype_l3_ipv4 = 1;
+ if (ptypes[i] & RTE_PTYPE_L3_IPV6)
+ ptype_l3_ipv6 = 1;
+ }
+ free(ptypes);
+
+ if (ptype_l3_ipv4 == 0)
+ printf("port %d cannot parse RTE_PTYPE_L3_IPV4\n", portid);
+
+ if (ptype_l3_ipv6 == 0)
+ printf("port %d cannot parse RTE_PTYPE_L3_IPV6\n", portid);
+
+ if (ptype_l3_ipv4 && ptype_l3_ipv6)
+ return 1;
+
+ return 0;
+}
+stati
[dpdk-dev] [PATCH v2 01/12] ethdev: add API to query packet type filling info
On 2/25/2016 7:17 PM, Ananyev, Konstantin wrote:
+int
+rte_eth_dev_get_ptype_info(uint8_t port_id, uint32_t ptype_mask,
+ uint32_t ptypes[], int num)
+{
+ int ret, i, j;
+ struct rte_eth_dev *dev;
+ uint32_t all_ptypes[RTE_PTYPE_MAX_NUM];
+
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+ dev = &rte_eth_devices[port_id];
+ RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_ptype_info_get, -ENOTSUP);
+ ret = (*dev->dev_ops->dev_ptype_info_get)(dev, all_ptypes);
+
+ for (i = 0, j = 0; i < ret && j < num; ++i)
+ if (all_ptypes[i] & ptype_mask)
+ ptypes[j++] = all_ptypes[i];
+
+ return ret;
>>> I think it needs to be something like:
>>>
>>> j = 0;
>>> for (i = 0, j = 0; i < ret; ++i) {
>>>if (all_ptypes[i] & ptype_mask) {
>>> if (j < num)
>>> ptypes[j] = all_ptypes[i];
>>> j++;
>>> }
>>> }
>>>
>>> return j;
>>>
>>> Konstantin
>>>
>> You are right, my previous code is wrong.
>> But I have a concern about your code above: under the condition that the
>> caller does not provide big enough array to store adequate ptypes, it
>> has no way to return the not-enough-memory message back to caller.
>>
>> So under that condition, how about we just return -ENOMEM?
>>
> As I remember, the agreement was - we don't return an -ENOMEM in that case.
> What we do return - number of entries in ptypes[] that would be required to
> store all adequate ptypes (similar to what snprinf() does).
> So the user can do something like that (if he needs to):
>
> num = rte_eth_dev_get_ptype_info(port, ptype_mask, NULL, 0);
> if (num < 0) {/*error handling*/}
> ptypes = alloca(num * ptypes[0]);
> n = rte_eth_dev_get_ptype_info(port, ptype_mask, ptypes, num);
> ...
>
> Konstantin
>
Oh, yes. Sorry, I previously misunderstood your code.
But I still have a concern of above way that this APIs should be called
two times. I suggest to use a way, like strdup, callee to malloc, caller
to free. I send out v3 right now, please have a look at if it's OK.
Thanks,
Jianfeng
[dpdk-dev] [PATCH v2 4/6] bond mode 4: allow external state machine
Hi Eric,
> > @@ -157,6 +159,7 @@ struct rte_eth_bond_8023ad_conf {
> > uint32_t tx_period_ms;
> > uint32_t rx_marker_period_ms;
> > uint32_t update_timeout_ms;
> > + rte_eth_bond_8023ad_ext_slowrx_fn slowrx_cb;
> > };
>
> This still is a likely an ABI break, previously discussed around here:
> http://dpdk.org/ml/archives/dev/2015-November/027321.html
>
> It might not be embedded anywhere in DPDK codebase, but there's no
> telling what others might have done with it (have an array of them, embed in
> other structs etc).
>
> Also ultimately ABI compatibility goes both ways: when the library soname
> does not change then an application is free to assume both downgrading and
> upgrading are safe. In this case, upgrading *might* be okay, downgrading
> certainly is not. So by that measure it definitely is an ABI break.
>
> [...]
> > diff --git a/drivers/net/bonding/rte_eth_bond_version.map
> > b/drivers/net/bonding/rte_eth_bond_version.map
> > index 22bd920..33d73ff 100644
> > --- a/drivers/net/bonding/rte_eth_bond_version.map
> > +++ b/drivers/net/bonding/rte_eth_bond_version.map
> > @@ -27,3 +27,9 @@ DPDK_2.1 {
> > rte_eth_bond_free;
> >
> > } DPDK_2.0;
> > +
> > +DPDK_2.2 {
> > + rte_eth_bond_8023ad_ext_collect;
> > + rte_eth_bond_8023ad_ext_distrib;
> > + rte_eth_bond_8023ad_ext_slowtx;
> > +} DPDK_2.1;
> >
>
> These symbols are not part of DPDK 2.2, the version here is wrong.
> Technically it would not actually matter much but better not to confuse
> things unnecessarily.
>
> - Panu -
It looks like Panu's points are valid, a V3 of this patch set which takes care
of these issues will be needed.
Patches 1/6, 5/6 and 6/6 of the patch set are bug fixes, so each patch should
contain a fixes line.
Patches 2/6, 3/6 and 4/6 are a new feature, the release notes should be updated
for this feature.
Could I suggest splitting the patch set into two patch sets, a bug fix patch
set and a new feature patch set.
Regards,
Bernard.
[dpdk-dev] [PATCH v3 1/3] fm10k: enable FTAG based forwarding
Hi, Bruce, > -Original Message- > From: Richardson, Bruce > Sent: Thursday, February 25, 2016 9:35 PM > To: Chen, Jing D > Cc: Thomas Monjalon ; Wang, Xiao W > ; dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH v3 1/3] fm10k: enable FTAG based > forwarding > > On Thu, Feb 25, 2016 at 10:04:02AM +, Chen, Jing D wrote: > > Hi, Bruce, Thomas, > > > > Best Regards, > > Mark > > > > > -Original Message- > > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas > Monjalon > > > Sent: Thursday, February 25, 2016 12:38 AM > > > To: Richardson, Bruce; Wang, Xiao W > > > Cc: dev at dpdk.org > > > Subject: Re: [dpdk-dev] [PATCH v3 1/3] fm10k: enable FTAG based > > > forwarding > > > > > > 2016-02-24 15:42, Bruce Richardson: > > > > On Thu, Feb 04, 2016 at 11:38:47AM +0800, Wang Xiao W wrote: > > > > > 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 > > > > > > > > Any comments on this patch? > > > > > > > > My thoughts: is there a way in which this could be done without > > > > adding in a > > > new > > > > build time config option? > > > > > > Bruce, it's simpler to explain that build time options are forbidden > > > to enable such options. > > > Or the terrific kid's approach: one day, the Big Build-Option Eater > > > will come and will eat every undecided features! ;) > > > > This feature is trying to use FTAG (a unique tech in fm10k) instead of > > mac/vlan to forward packets. App need a way to tell PMD driver that > > which forwarding style it would like to use. > > Why not just specify this in the port configuration at setup time? > Please educate me. I think the port configuration flags are also common to all PMD Drivers. Is it possible to add a flag like "RTE_USE_FTAG" and pass to PMD driver? > > So, the best option is to let packets carry a flag in mbuf to tell drive in > > fast > path. > > You can see that this is unique to fm10k and we thought community > > won't like to see this flag introduced into mbuf. If you do agree, we can > introduce a new flag. > > Why does it need to be specified per-mbuf? The existing config flag added is > global, so a per-mbuf flag shouldn't be needed to get equivalent behaviour. > > > So, we step backwards and assume customer will use static > > configurations to enable this feature. After it is enabled, we'll assume app > will use FTAG for all packets. > > Yes, but instead of compile time option, why not port config-time option > instead? > > /Bruce
[dpdk-dev] [PATCH v3 01/12] ethdev: add API to query packet type filling info
Hi Jainfeng,
>
> Add a new API rte_eth_dev_get_ptype_info to query whether/what packet
> type can be filled by given pmd rx burst function.
>
> Signed-off-by: Jianfeng Tan
> ---
> lib/librte_ether/rte_ethdev.c | 32
> lib/librte_ether/rte_ethdev.h | 23 +++
> 2 files changed, 55 insertions(+)
>
> diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
> index 1257965..b52555b 100644
> --- a/lib/librte_ether/rte_ethdev.c
> +++ b/lib/librte_ether/rte_ethdev.c
> @@ -1576,6 +1576,38 @@ rte_eth_dev_info_get(uint8_t port_id, struct
> rte_eth_dev_info *dev_info)
> dev_info->driver_name = dev->data->drv_name;
> }
>
> +int
> +rte_eth_dev_get_ptype_info(uint8_t port_id, uint32_t ptype_mask,
> +uint32_t **p_ptypes)
> +{
> + int i, j, ret;
> + struct rte_eth_dev *dev;
> + const uint32_t *all_ptypes;
> +
> + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> + dev = &rte_eth_devices[port_id];
> + RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_ptype_info_get, -ENOTSUP);
> + all_ptypes = (*dev->dev_ops->dev_ptype_info_get)(dev);
> +
> + if (!all_ptypes)
> + return 0;
> +
> + for (i = 0, ret = 0; all_ptypes[i] != RTE_PTYPE_UNKNOWN; ++i)
> + if (all_ptypes[i] & ptype_mask)
> + ret++;
> + if (ret == 0)
> + return 0;
> +
> + *p_ptypes = (uint32_t *)malloc(sizeof(uint32_t) * ret);
> + if (*p_ptypes == NULL)
> + return -ENOMEM;
I thought we all agreed to follow snprintf()-like logic and avoid any memory
allocations inside that function.
So why malloc() again?
Konstantin
> +
> + for (i = 0, j = 0; all_ptypes[i] != RTE_PTYPE_UNKNOWN; ++i)
> + if (all_ptypes[i] & ptype_mask)
> + *p_ptypes[j++] = all_ptypes[i];
> + return ret;
> +}
> +
> void
> rte_eth_macaddr_get(uint8_t port_id, struct ether_addr *mac_addr)
> {
> diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
> index 16da821..341e2ff 100644
> --- a/lib/librte_ether/rte_ethdev.h
> +++ b/lib/librte_ether/rte_ethdev.h
> @@ -1021,6 +1021,9 @@ typedef void (*eth_dev_infos_get_t)(struct rte_eth_dev
> *dev,
> struct rte_eth_dev_info *dev_info);
> /**< @internal Get specific informations of an Ethernet device. */
>
> +typedef const uint32_t *(*eth_dev_ptype_info_get_t)(struct rte_eth_dev *dev);
> +/**< @internal Get ptype info of eth_rx_burst_t. */
> +
> typedef int (*eth_queue_start_t)(struct rte_eth_dev *dev,
> uint16_t queue_id);
> /**< @internal Start rx and tx of a queue of an Ethernet device. */
> @@ -1347,6 +1350,7 @@ struct eth_dev_ops {
> eth_queue_stats_mapping_set_t queue_stats_mapping_set;
> /**< Configure per queue stat counter mapping. */
> eth_dev_infos_get_tdev_infos_get; /**< Get device info. */
> + eth_dev_ptype_info_get_t dev_ptype_info_get; /** Get ptype info */
> mtu_set_t mtu_set; /**< Set MTU. */
> vlan_filter_set_t vlan_filter_set; /**< Filter VLAN Setup. */
> vlan_tpid_set_tvlan_tpid_set; /**< Outer VLAN TPID
> Setup. */
> @@ -2268,6 +2272,25 @@ void rte_eth_macaddr_get(uint8_t port_id, struct
> ether_addr *mac_addr);
> void rte_eth_dev_info_get(uint8_t port_id, struct rte_eth_dev_info
> *dev_info);
>
> /**
> + * Retrieve the packet type information of an Ethernet device.
> + *
> + * @param port_id
> + * The port identifier of the Ethernet device.
> + * @param ptype_mask
> + * A hint of what kind of packet type which the caller is interested in.
> + * @param p_ptypes
> + * A pointer to store address of adequent packet types array. Caller to
> free.
> + * @return
> + * - (>0) Number of ptypes supported. Need caller to free the array.
> + * - (0 or -ENOTSUP) if PMD does not fill the specified ptype.
> + * - (-ENOMEM) if fail to malloc required memory to store ptypes.
> + * - (-ENODEV) if *port_id* invalid.
> + */
> +extern int rte_eth_dev_get_ptype_info(uint8_t port_id,
> + uint32_t ptype_mask,
> + uint32_t **p_ptypes);
> +
> +/**
> * Retrieve the MTU of an Ethernet device.
> *
> * @param port_id
> --
> 2.1.4
[dpdk-dev] [PATCH v3 1/3] fm10k: enable FTAG based forwarding
On Thu, Feb 25, 2016 at 03:45:45PM +, Chen, Jing D wrote: > Hi, Bruce, > > > -Original Message- > > From: Richardson, Bruce > > Sent: Thursday, February 25, 2016 9:35 PM > > To: Chen, Jing D > > Cc: Thomas Monjalon ; Wang, Xiao W > > ; dev at dpdk.org > > Subject: Re: [dpdk-dev] [PATCH v3 1/3] fm10k: enable FTAG based > > forwarding > > > > On Thu, Feb 25, 2016 at 10:04:02AM +, Chen, Jing D wrote: > > > Hi, Bruce, Thomas, > > > > > > Best Regards, > > > Mark > > > > > > > -Original Message- > > > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas > > Monjalon > > > > Sent: Thursday, February 25, 2016 12:38 AM > > > > To: Richardson, Bruce; Wang, Xiao W > > > > Cc: dev at dpdk.org > > > > Subject: Re: [dpdk-dev] [PATCH v3 1/3] fm10k: enable FTAG based > > > > forwarding > > > > > > > > 2016-02-24 15:42, Bruce Richardson: > > > > > On Thu, Feb 04, 2016 at 11:38:47AM +0800, Wang Xiao W wrote: > > > > > > 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 > > > > > > > > > > Any comments on this patch? > > > > > > > > > > My thoughts: is there a way in which this could be done without > > > > > adding in a > > > > new > > > > > build time config option? > > > > > > > > Bruce, it's simpler to explain that build time options are forbidden > > > > to enable such options. > > > > Or the terrific kid's approach: one day, the Big Build-Option Eater > > > > will come and will eat every undecided features! ;) > > > > > > This feature is trying to use FTAG (a unique tech in fm10k) instead of > > > mac/vlan to forward packets. App need a way to tell PMD driver that > > > which forwarding style it would like to use. > > > > Why not just specify this in the port configuration at setup time? > > > > Please educate me. I think the port configuration flags are also common to > all PMD > Drivers. Is it possible to add a flag like "RTE_USE_FTAG" and pass to PMD > driver? > They are. For something PMD specific, like FTAG, it's always a challenge, and I don't know off the top of my head if there is a simple option. However, given the choice between an mbuf flag and a port config flag, I'd always choose the former. Other alternatives would be to have a fm10k specific API in the fm10k driver alone. I'll let Thomas as ethdev maintainer comment if he has other suggestions as to how to handle this case. I suspect this won't be the first device-specific piece of functionality we need to deal with. /Bruce
[dpdk-dev] [PATCH v2 0/2] add support for buffered tx to ethdev
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Tomasz Kulasek
> Sent: Wednesday, February 24, 2016 5:09 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v2 0/2] add support for buffered tx to ethdev
>
> Many sample apps include internal buffering for single-packet-at-a-time
> operation. Since this is such a common paradigm, this functionality is
> better suited to being implemented in the ethdev API.
>
> The new APIs in the ethdev library are:
> * rte_eth_tx_buffer_init - initialize buffer
> * rte_eth_tx_buffer - buffer up a single packet for future transmission
> * rte_eth_tx_buffer_flush - flush any unsent buffered packets
> * rte_eth_tx_buffer_set_err_callback - set up a callback to be called in
> case transmitting a buffered burst fails. By default, we just free the
> unsent packets.
>
> As well as these, an additional reference callback is provided, which
> frees the packets (as the default callback does), as well as updating a
> user-provided counter, so that the number of dropped packets can be
> tracked.
>
> Due to the feedback from mailing list, that buffer management facilities
> in the user application are more preferable than API simplicity, we decided
> to move internal buffer table, as well as callback functions and user data,
> from rte_eth_dev/rte_eth_dev_data to the application space.
> It prevents ABI breakage and gives some more flexibility in the buffer's
> management such as allocation, dynamical size change, reuse buffers on many
> ports or after fail, and so on.
>
>
> The following steps illustrate how tx buffers can be used in application:
>
> 1) Initialization
>
> a) Allocate memory for a buffer
>
>struct rte_eth_dev_tx_buffer *buffer = rte_zmalloc_socket("tx_buffer",
>RTE_ETH_TX_BUFFER_SIZE(MAX_PKT_BURST), 0, socket_id);
>
>RTE_ETH_TX_BUFFER_SIZE(size) macro computes memory required to store
>"size" packets in buffer.
>
> b) Initialize allocated memory and set up default values. Threshold level
>must be lower than or equal to the MAX_PKT_BURST from 1a)
>
>rte_eth_tx_buffer_init(buffer, threshold);
>
>
> c) Set error callback (optional)
>
>rte_eth_tx_buffer_set_err_callback(buffer, callback_fn, userdata);
>
>
> 2) Store packet "pkt" in buffer and send them all to the queue_id on
>port_id when number of packets reaches threshold level set up in 1b)
>
>rte_eth_tx_buffer(port_id, queue_id, buffer, pkt);
>
>
> 3) Send all stored packets to the queue_id on port_id
>
>rte_eth_tx_buffer_flush(port_id, queue_id, buffer);
>
>
> 4) Flush buffer and free memory
>
>rte_eth_tx_buffer_flush(port_id, queue_id, buffer);
>...
>rte_free(buffer);
>
>
> v2 changes:
> - reworked to use new buffer model
> - buffer data and callbacks are removed from rte_eth_dev/rte_eth_dev_data,
>so this patch doesn't brake an ABI anymore
> - introduced RTE_ETH_TX_BUFFER macro and rte_eth_tx_buffer_init
> - buffers are not attached to the port-queue
> - buffers can be allocated dynamically during application work
> - size of buffer can be changed without port restart
>
>
> Tomasz Kulasek (2):
> ethdev: add buffered tx api
> examples: rework to use buffered tx
>
> examples/l2fwd-jobstats/main.c | 104 +--
> examples/l2fwd-keepalive/main.c| 100 ---
> examples/l2fwd/main.c | 104 +--
> examples/l3fwd-acl/main.c | 92 --
> examples/l3fwd-power/main.c| 89 --
> examples/link_status_interrupt/main.c | 107 +---
> .../client_server_mp/mp_client/client.c| 101 ++-
> examples/multi_process/l2fwd_fork/main.c | 97 +--
> examples/packet_ordering/main.c| 122 +
> examples/qos_meter/main.c | 61 ++-
> lib/librte_ether/rte_ethdev.c | 36
> lib/librte_ether/rte_ethdev.h | 182
> +++-
> lib/librte_ether/rte_ether_version.map |9 +
> 13 files changed, 662 insertions(+), 542 deletions(-)
>
Acked-by: Konstantin Ananyev
> --
> 1.7.9.5
[dpdk-dev] [PATCH 00/19] fix hard-coded references in sample apps guide
MANY references in the sample applications user guide are wrong because they are hard-coded and section numbers have changed over the time. This patch set changes thoses references to dynamic ones, in this way if section numbers change the reference get updated automatically. Mauricio Vasquez B (19): doc: fix vhost sample app hard-coded references doc: fix distributor sample application hard-coded references doc: fix exception path sample app hard-coded references doc: fix intel quickAssist technology sample app hard-coded references doc: fix ip fragmentation sample app hard-coded references doc: fix ip reassembly sample app hard-coded references doc: fix multicast sample app hard-coded references doc: fix kepp alive sample app hard-coded references doc: fix kni sample app hard-coded references doc: fix l2 fwd sample app hard-coded references doc: fix l3 fwd sample app hard-coded references doc: fix l3fwd access control sample app hard-coded references doc: fix l3fwd power man sample app hard-coded references doc: fix l3fwd virtual sample app hard-coded references doc: fix link status int sample app hard-coded references doc: fix multi-process sample app hard-coded references doc: fix tep termination sample app hard-coded references doc: fix vmdq and dcb fwd sample app hard-coded references doc: fix vm power man sample app hard-coded references doc/guides/sample_app_ug/dist_app.rst| 10 +- doc/guides/sample_app_ug/exception_path.rst | 5 ++--- doc/guides/sample_app_ug/intel_quickassist.rst | 2 +- doc/guides/sample_app_ug/ip_frag.rst | 3 +-- doc/guides/sample_app_ug/ip_reassembly.rst | 6 ++ doc/guides/sample_app_ug/ipv4_multicast.rst | 6 ++ doc/guides/sample_app_ug/keep_alive.rst | 6 ++ doc/guides/sample_app_ug/kernel_nic_interface.rst| 7 +++ doc/guides/sample_app_ug/l2_forward_real_virtual.rst | 19 +-- doc/guides/sample_app_ug/l3_forward.rst | 8 doc/guides/sample_app_ug/l3_forward_access_ctrl.rst | 6 ++ doc/guides/sample_app_ug/l3_forward_power_man.rst| 5 ++--- doc/guides/sample_app_ug/l3_forward_virtual.rst | 7 +++ doc/guides/sample_app_ug/link_status_intr.rst| 8 doc/guides/sample_app_ug/multi_process.rst | 4 ++-- doc/guides/sample_app_ug/tep_termination.rst | 8 doc/guides/sample_app_ug/vhost.rst | 13 ++--- doc/guides/sample_app_ug/vm_power_management.rst | 4 ++-- doc/guides/sample_app_ug/vmdq_dcb_forwarding.rst | 6 +++--- 19 files changed, 71 insertions(+), 62 deletions(-) -- 1.9.1
[dpdk-dev] [PATCH 02/19] doc: fix distributor sample application hard-coded references
Signed-off-by: Mauricio Vasquez B --- doc/guides/sample_app_ug/dist_app.rst| 10 +- doc/guides/sample_app_ug/l2_forward_real_virtual.rst | 10 ++ 2 files changed, 15 insertions(+), 5 deletions(-) diff --git a/doc/guides/sample_app_ug/dist_app.rst b/doc/guides/sample_app_ug/dist_app.rst index 3c9a991..e242748 100644 --- a/doc/guides/sample_app_ug/dist_app.rst +++ b/doc/guides/sample_app_ug/dist_app.rst @@ -160,16 +160,16 @@ Application Initialization -- Command line parsing is done in the same way as it is done in the L2 Forwarding Sample -Application. See Section 9.4.1, "Command Line Arguments". +Application. See :ref:`l2_fwd_app_cmd_arguments`. Mbuf pool initialization is done in the same way as it is done in the L2 Forwarding -Sample Application. See Section 9.4.2, "Mbuf Pool Initialization". +Sample Application. See :ref:`l2_fwd_app_mbuf_init`. Driver Initialization is done in same way as it is done in the L2 Forwarding Sample -Application. See Section 9.4.3, "Driver Initialization". +Application. See :ref:`l2_fwd_app_dvr_init`. RX queue initialization is done in the same way as it is done in the L2 Forwarding -Sample Application. See Section 9.4.4, "RX Queue Initialization". +Sample Application. See :ref:`l2_fwd_app_rx_init`. TX queue initialization is done in the same way as it is done in the L2 Forwarding -Sample Application. See Section 9.4.5, "TX Queue Initialization". +Sample Application. See :ref:`l2_fwd_app_tx_init`. diff --git a/doc/guides/sample_app_ug/l2_forward_real_virtual.rst b/doc/guides/sample_app_ug/l2_forward_real_virtual.rst index 65a3cec..6e61b4b 100644 --- a/doc/guides/sample_app_ug/l2_forward_real_virtual.rst +++ b/doc/guides/sample_app_ug/l2_forward_real_virtual.rst @@ -147,6 +147,8 @@ Explanation The following sections provide some explanation of the code. +.. _l2_fwd_app_cmd_arguments: + Command Line Arguments ~~ @@ -179,6 +181,8 @@ This is done at the beginning of the main() function: if (ret < 0) rte_exit(EXIT_FAILURE, "Invalid L2FWD arguments\n"); +.. _l2_fwd_app_mbuf_init: + Mbuf Pool Initialization @@ -216,6 +220,8 @@ Two callback pointers are also given to the rte_mempool_create() function: If a more complex application wants to extend the rte_pktmbuf structure for its own needs, a new function derived from rte_pktmbuf_init( ) can be created. +.. _l2_fwd_app_dvr_init: + Driver Initialization ~ @@ -303,6 +309,8 @@ The global configuration is stored in a static structure: }, }; +.. _l2_fwd_app_rx_init: + RX Queue Initialization ~~~ @@ -349,6 +357,8 @@ The global configuration for the RX queues is stored in a static structure: }, }; +.. _l2_fwd_app_tx_init: + TX Queue Initialization ~~~ -- 1.9.1
[dpdk-dev] [PATCH 01/19] doc: fix vhost sample app hard-coded references
Signed-off-by: Mauricio Vasquez B --- doc/guides/sample_app_ug/vhost.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/doc/guides/sample_app_ug/vhost.rst b/doc/guides/sample_app_ug/vhost.rst index e5d1326..751656c 100644 --- a/doc/guides/sample_app_ug/vhost.rst +++ b/doc/guides/sample_app_ug/vhost.rst @@ -260,7 +260,7 @@ Setting up the Guest Execution Environment ~~ It is recommended for testing purposes that the DPDK testpmd sample application is used in the guest to forward packets, -the reasons for this are discussed in Section 22.7, "Running the Virtual Machine (QEMU)". +the reasons for this are discussed in `Running the Virtual Machine (QEMU)`_. The testpmd application forwards packets between pairs of Ethernet devices, it requires an even number of Ethernet devices (virtio or otherwise) to execute. @@ -583,7 +583,7 @@ an open file descriptor must be passed to QEMU running as a child process. .. note:: -This process is automated in the QEMU wrapper script discussed in Section 24.7.3. +This process is automated in the `QEMU Wrapper Script`_. Mapping the Virtual Machine's Memory @@ -600,7 +600,7 @@ In this case, the path passed to the guest should be that of the 1 GB page huget .. note:: -This process is automated in the QEMU wrapper script discussed in Section 24.7.3. +This process is automated in the `QEMU Wrapper Script`_. The following two sections only applies to vhost cuse. For vhost-user, please make corresponding changes to qemu-wrapper script and guest XML file. -- 1.9.1
[dpdk-dev] [PATCH 03/19] doc: fix exception path sample app hard-coded references
Signed-off-by: Mauricio Vasquez B --- doc/guides/sample_app_ug/exception_path.rst | 5 ++--- doc/guides/sample_app_ug/l2_forward_real_virtual.rst | 4 2 files changed, 6 insertions(+), 3 deletions(-) diff --git a/doc/guides/sample_app_ug/exception_path.rst b/doc/guides/sample_app_ug/exception_path.rst index c3f8f88..161b6e0 100644 --- a/doc/guides/sample_app_ug/exception_path.rst +++ b/doc/guides/sample_app_ug/exception_path.rst @@ -134,8 +134,7 @@ The following sections provide some explanation of the code. Initialization ~~ -Setup of the mbuf pool, driver and queues is similar to the setup done in the L2 Forwarding sample application -(see Chapter 9 "L2 forwarding Sample Application (in Real and Virtualized Environments" for details). +Setup of the mbuf pool, driver and queues is similar to the setup done in the :ref:`l2_fwd_app_real_and_virtual`. In addition, the TAP interfaces must also be created. A TAP interface is created for each lcore that is being used. The code for creating the TAP interface is as follows: @@ -221,7 +220,7 @@ This function first checks the lcore_id against the user provided input_cores_ma if this core is reading from or writing to a TAP interface. For the case that reads from a NIC port, the packet reception is the same as in the L2 Forwarding sample application -(see Section 9.4.6, "Receive, Process and Transmit Packets"). +(see :ref:`l2_fwd_app_rx_tx_packets`). The packet transmission is done by calling write() with the file descriptor of the appropriate TAP interface and then explicitly freeing the mbuf back to the pool. diff --git a/doc/guides/sample_app_ug/l2_forward_real_virtual.rst b/doc/guides/sample_app_ug/l2_forward_real_virtual.rst index 6e61b4b..12f0d27 100644 --- a/doc/guides/sample_app_ug/l2_forward_real_virtual.rst +++ b/doc/guides/sample_app_ug/l2_forward_real_virtual.rst @@ -28,6 +28,8 @@ (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. +.. _l2_fwd_app_real_and_virtual: + L2 Forwarding Sample Application (in Real and Virtualized Environments) === @@ -387,6 +389,8 @@ The global configuration for TX queues is stored in a static structure: .tx_free_thresh = RTE_TEST_TX_DESC_DEFAULT + 1, /* disable feature */ }; +.. _l2_fwd_app_rx_tx_packets: + Receive, Process and Transmit Packets ~ -- 1.9.1
[dpdk-dev] [PATCH 04/19] doc: fix intel quickAssist technology sample app hard-coded references
Signed-off-by: Mauricio Vasquez B --- doc/guides/sample_app_ug/intel_quickassist.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/guides/sample_app_ug/intel_quickassist.rst b/doc/guides/sample_app_ug/intel_quickassist.rst index a80d4ca..04d1593 100644 --- a/doc/guides/sample_app_ug/intel_quickassist.rst +++ b/doc/guides/sample_app_ug/intel_quickassist.rst @@ -203,7 +203,7 @@ where, * --config'(port,queue,lcore)[,(port,queue,lcore)]': determines which queues from which ports are mapped to which cores. -Refer to Chapter 10 , "L3 Forwarding Sample Application" for more detailed descriptions of the --config command line option. +Refer to the :doc:`l3_forward` for more detailed descriptions of the --config command line option. As an example, to run the application with two ports and two cores, which are using different Intel?? QuickAssist Technology execution engines, -- 1.9.1
[dpdk-dev] [PATCH 05/19] doc: fix ip fragmentation sample app hard-coded references
Signed-off-by: Mauricio Vasquez B --- doc/guides/sample_app_ug/ip_frag.rst | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/doc/guides/sample_app_ug/ip_frag.rst b/doc/guides/sample_app_ug/ip_frag.rst index 0c18fff..0c8da19 100644 --- a/doc/guides/sample_app_ug/ip_frag.rst +++ b/doc/guides/sample_app_ug/ip_frag.rst @@ -39,8 +39,7 @@ Overview The application demonstrates the use of zero-copy buffers for packet fragmentation. -The initialization and run-time paths are very similar to those of the L2 forwarding application -(see Chapter 9 "L2 Forwarding Simple Application (in Real and Virtualized Environments)" for more information). +The initialization and run-time paths are very similar to those of the :doc:`l2_forward_real_virtual`. This guide highlights the differences between the two applications. There are three key differences from the L2 Forwarding sample application: -- 1.9.1
[dpdk-dev] [PATCH 10/19] doc: fix l2 fwd sample app hard-coded references
Signed-off-by: Mauricio Vasquez B --- doc/guides/sample_app_ug/l2_forward_real_virtual.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/guides/sample_app_ug/l2_forward_real_virtual.rst b/doc/guides/sample_app_ug/l2_forward_real_virtual.rst index 12f0d27..2a576f3 100644 --- a/doc/guides/sample_app_ug/l2_forward_real_virtual.rst +++ b/doc/guides/sample_app_ug/l2_forward_real_virtual.rst @@ -155,7 +155,7 @@ Command Line Arguments ~~ The L2 Forwarding sample application takes specific parameters, -in addition to Environment Abstraction Layer (EAL) arguments (see Section 9.3). +in addition to Environment Abstraction Layer (EAL) arguments. The preferred way to parse parameters is to use the getopt() function, since it is part of a well-defined and portable library. @@ -345,7 +345,7 @@ The list of queues that must be polled for a given lcore is stored in a private struct lcore_queue_conf lcore_queue_conf[RTE_MAX_LCORE]; The values n_rx_port and rx_port_list[] are used in the main packet processing loop -(see Section 9.4.6 "Receive, Process and Transmit Packets" later in this chapter). +(see :ref:`l2_fwd_app_rx_tx_packets`). The global configuration for the RX queues is stored in a static structure: -- 1.9.1
[dpdk-dev] [PATCH 07/19] doc: fix multicast sample app hard-coded references
Signed-off-by: Mauricio Vasquez B --- doc/guides/sample_app_ug/ipv4_multicast.rst | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/doc/guides/sample_app_ug/ipv4_multicast.rst b/doc/guides/sample_app_ug/ipv4_multicast.rst index ec76087..67ea944 100644 --- a/doc/guides/sample_app_ug/ipv4_multicast.rst +++ b/doc/guides/sample_app_ug/ipv4_multicast.rst @@ -39,8 +39,7 @@ Overview The application demonstrates the use of zero-copy buffers for packet forwarding. -The initialization and run-time paths are very similar to those of the L2 forwarding application -(see Chapter 9 "L2 Forwarding Sample Application (in Real and Virtualized Environments)" for details more information). +The initialization and run-time paths are very similar to those of the :doc:`l2_forward_real_virtual`. This guide highlights the differences between the two applications. There are two key differences from the L2 Forwarding sample application: @@ -134,8 +133,7 @@ Explanation The following sections provide some explanation of the code. As mentioned in the overview section, -the initialization and run-time paths are very similar to those of the L2 Forwarding sample application -(see Chapter 9 "L2 Forwarding Sample Application in Real and Virtualized Environments" for more information). +the initialization and run-time paths are very similar to those of the :doc:`l2_forward_real_virtual`. The following sections describe aspects that are specific to the IPv4 Multicast sample application. Memory Pool Initialization -- 1.9.1
[dpdk-dev] [PATCH 08/19] doc: fix kepp alive sample app hard-coded references
Signed-off-by: Mauricio Vasquez B --- doc/guides/sample_app_ug/keep_alive.rst | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/doc/guides/sample_app_ug/keep_alive.rst b/doc/guides/sample_app_ug/keep_alive.rst index 080811b..b00f43b 100644 --- a/doc/guides/sample_app_ug/keep_alive.rst +++ b/doc/guides/sample_app_ug/keep_alive.rst @@ -59,7 +59,7 @@ Note: Only the worker cores are monitored. A local (on the host) mechanism or agent to supervise the Keep Alive Monitor Agent Core DPDK core is required to detect its failure. -Note: This application is based on the L2 forwarding application. As +Note: This application is based on the :doc:`l2_forward_real_virtual`. As such, the initialization and run-time paths are very similar to those of the L2 forwarding application. @@ -127,9 +127,7 @@ Explanation The following sections provide some explanation of the The Keep-Alive/'Liveliness' conceptual scheme. As mentioned in the overview section, the initialization and run-time paths are very -similar to those of the L2 forwarding application (see Chapter 9 -"L2 Forwarding Sample Application (in Real and Virtualized -Environments)" for more information). +similar to those of the :doc:`l2_forward_real_virtual`. The Keep-Alive/'Liveliness' conceptual scheme: -- 1.9.1
[dpdk-dev] [PATCH 06/19] doc: fix ip reassembly sample app hard-coded references
Signed-off-by: Mauricio Vasquez B --- doc/guides/sample_app_ug/ip_reassembly.rst | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/doc/guides/sample_app_ug/ip_reassembly.rst b/doc/guides/sample_app_ug/ip_reassembly.rst index 6bf5938..3c5cc70 100644 --- a/doc/guides/sample_app_ug/ip_reassembly.rst +++ b/doc/guides/sample_app_ug/ip_reassembly.rst @@ -39,8 +39,7 @@ Overview The application demonstrates the use of the DPDK libraries to implement packet forwarding with reassembly for IPv4 and IPv6 fragmented packets. -The initialization and run- time paths are very similar to those of the L2 forwarding application -(see Chapter 9 "L2 Forwarding Sample Application" for more information). +The initialization and run- time paths are very similar to those of the :doc:`l2_forward_real_virtual`. The main difference from the L2 Forwarding sample application is that it reassembles fragmented IPv4 and IPv6 packets before forwarding. The maximum allowed size of reassembled packet is 9.5 KB. @@ -182,8 +181,7 @@ Explanation --- The following sections provide some explanation of the sample application code. -As mentioned in the overview section, the initialization and run-time paths are very similar to those of the L2 forwarding application -(see Chapter 9 "L2 Forwarding Sample Application" for more information). +As mentioned in the overview section, the initialization and run-time paths are very similar to those of the :doc:`l2_forward_real_virtual`. The following sections describe aspects that are specific to the IP reassemble sample application. IPv4 Fragment Table Initialization -- 1.9.1
[dpdk-dev] [PATCH 11/19] doc: fix l3 fwd sample app hard-coded references
Signed-off-by: Mauricio Vasquez B --- doc/guides/sample_app_ug/l3_forward.rst | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/doc/guides/sample_app_ug/l3_forward.rst b/doc/guides/sample_app_ug/l3_forward.rst index 4ce734b..1aac7dd 100644 --- a/doc/guides/sample_app_ug/l3_forward.rst +++ b/doc/guides/sample_app_ug/l3_forward.rst @@ -38,8 +38,7 @@ Overview The application demonstrates the use of the hash and LPM libraries in the DPDK to implement packet forwarding. -The initialization and run-time paths are very similar to those of the L2 forwarding application -(see Chapter 9 "L2 Forwarding Sample Application (in Real and Virtualized Environments)" for more information). +The initialization and run-time paths are very similar to those of the :doc:`l2_forward_real_virtual`. The main difference from the L2 Forwarding sample application is that the forwarding decision is made based on information read from the input packet. @@ -161,8 +160,7 @@ Explanation --- The following sections provide some explanation of the sample application code. As mentioned in the overview section, -the initialization and run-time paths are very similar to those of the L2 forwarding application -(see Chapter 9 "L2 Forwarding Sample Application (in Real and Virtualized Environments)" for more information). +the initialization and run-time paths are very similar to those of the :doc:`l2_forward_real_virtual`. The following sections describe aspects that are specific to the L3 Forwarding sample application. Hash Initialization -- 1.9.1
[dpdk-dev] [PATCH 14/19] doc: fix l3fwd virtual sample app hard-coded references
Signed-off-by: Mauricio Vasquez B --- doc/guides/sample_app_ug/l2_forward_real_virtual.rst | 1 + doc/guides/sample_app_ug/l3_forward.rst | 2 ++ doc/guides/sample_app_ug/l3_forward_virtual.rst | 7 +++ 3 files changed, 6 insertions(+), 4 deletions(-) diff --git a/doc/guides/sample_app_ug/l2_forward_real_virtual.rst b/doc/guides/sample_app_ug/l2_forward_real_virtual.rst index 2a576f3..e77d67c 100644 --- a/doc/guides/sample_app_ug/l2_forward_real_virtual.rst +++ b/doc/guides/sample_app_ug/l2_forward_real_virtual.rst @@ -75,6 +75,7 @@ The L2 Forwarding application can also be used as a starting point for developin Performance Benchmark Setup (Virtualized Environment) +.. _l2_fwd_vf_setup: Virtual Function Setup Instructions ~~~ diff --git a/doc/guides/sample_app_ug/l3_forward.rst b/doc/guides/sample_app_ug/l3_forward.rst index 1aac7dd..1522650 100644 --- a/doc/guides/sample_app_ug/l3_forward.rst +++ b/doc/guides/sample_app_ug/l3_forward.rst @@ -156,6 +156,8 @@ In this command: Refer to the *DPDK Getting Started Guide* for general information on running applications and the Environment Abstraction Layer (EAL) options. +.. _l3_fwd_explanation: + Explanation --- diff --git a/doc/guides/sample_app_ug/l3_forward_virtual.rst b/doc/guides/sample_app_ug/l3_forward_virtual.rst index f40643a..fa04722 100644 --- a/doc/guides/sample_app_ug/l3_forward_virtual.rst +++ b/doc/guides/sample_app_ug/l3_forward_virtual.rst @@ -39,8 +39,7 @@ Overview The application demonstrates the use of the hash and LPM libraries in the DPDK to implement packet forwarding. -The initialization and run-time paths are very similar to those of the L3 forwarding application -(see Chapter 10 "L3 Forwarding Sample Application" for more information). +The initialization and run-time paths are very similar to those of the :doc:`l3_forward`. The forwarding decision is taken based on information read from the input packet. The lookup method is either hash-based or LPM-based and is selected at compile time. @@ -60,7 +59,7 @@ The set of LPM rules used by the application is statically configured and loaded .. note:: -Please refer to Section 9.1.1 "Virtual Function Setup Instructions" for virtualized test case setup. +Please refer to :ref:`l2_fwd_vf_setup` for virtualized test case setup. Compiling the Application - @@ -155,4 +154,4 @@ Explanation --- The operation of this application is similar to that of the basic L3 Forwarding Sample Application. -See Section 10.4 "Explanation" for more information. +See :ref:`l3_fwd_explanation` for more information. -- 1.9.1
[dpdk-dev] [PATCH 09/19] doc: fix kni sample app hard-coded references
Signed-off-by: Mauricio Vasquez B --- doc/guides/sample_app_ug/kernel_nic_interface.rst | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/doc/guides/sample_app_ug/kernel_nic_interface.rst b/doc/guides/sample_app_ug/kernel_nic_interface.rst index 985c664..2ae9b70 100644 --- a/doc/guides/sample_app_ug/kernel_nic_interface.rst +++ b/doc/guides/sample_app_ug/kernel_nic_interface.rst @@ -237,8 +237,7 @@ The following sections provide some explanation of code. Initialization ~~ -Setup of mbuf pool, driver and queues is similar to the setup done in the L2 Forwarding sample application -(see Chapter 9 "L2 Forwarding Sample Application (in Real and Virtualized Environments" for details). +Setup of mbuf pool, driver and queues is similar to the setup done in the :doc:`l2_forward_real_virtual`.. In addition, one or more kernel NIC interfaces are allocated for each of the configured ports according to the command line parameters. @@ -425,7 +424,7 @@ to see if this lcore is reading from or writing to kernel NIC interfaces. For the case that reads from a NIC port and writes to the kernel NIC interfaces, the packet reception is the same as in L2 Forwarding sample application -(see Section 9.4.6 "Receive, Process and Transmit Packets"). +(see :ref:`l2_fwd_app_rx_tx_packets`). The packet transmission is done by sending mbufs into the kernel NIC interfaces by rte_kni_tx_burst(). The KNI library automatically frees the mbufs after the kernel successfully copied the mbufs. @@ -472,7 +471,7 @@ The KNI library automatically frees the mbufs after the kernel successfully copi For the other case that reads from kernel NIC interfaces and writes to a physical NIC port, packets are retrieved by reading mbufs from kernel NIC interfaces by `rte_kni_rx_burst()`. The packet transmission is the same as in the L2 Forwarding sample application -(see Section 9.4.6 "Receive, Process and Transmit Packet's"). +(see :ref:`l2_fwd_app_rx_tx_packets`). .. code-block:: c -- 1.9.1
[dpdk-dev] [PATCH 13/19] doc: fix l3fwd power man sample app hard-coded references
Signed-off-by: Mauricio Vasquez B --- doc/guides/sample_app_ug/l3_forward_power_man.rst | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/doc/guides/sample_app_ug/l3_forward_power_man.rst b/doc/guides/sample_app_ug/l3_forward_power_man.rst index ac688f8..ea9c404 100644 --- a/doc/guides/sample_app_ug/l3_forward_power_man.rst +++ b/doc/guides/sample_app_ug/l3_forward_power_man.rst @@ -43,8 +43,7 @@ Overview The application demonstrates the use of the Power libraries in the DPDK to implement packet forwarding. -The initialization and run-time paths are very similar to those of the L3 forwarding sample application -(see Chapter 10 "L3 Forwarding Sample Application" for more information). +The initialization and run-time paths are very similar to those of the :doc:`l3_forward`. The main difference from the L3 Forwarding sample application is that this application introduces power-aware optimization algorithms by leveraging the Power library to control P-state and C-state of processor based on packet load. @@ -152,7 +151,7 @@ where, * --no-numa: optional, disables numa awareness -See Chapter 10 "L3 Forwarding Sample Application" for details. +See :doc:`l3_forward` for details. The L3fwd-power example reuses the L3fwd command line options. Explanation -- 1.9.1
[dpdk-dev] [PATCH 19/19] doc: fix vm power man sample app hard-coded references
Signed-off-by: Mauricio Vasquez B --- doc/guides/sample_app_ug/vm_power_management.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/guides/sample_app_ug/vm_power_management.rst b/doc/guides/sample_app_ug/vm_power_management.rst index da8be12..7f299e0 100644 --- a/doc/guides/sample_app_ug/vm_power_management.rst +++ b/doc/guides/sample_app_ug/vm_power_management.rst @@ -72,7 +72,7 @@ The solution is comprised of two high-level components: the APCI cpufreq sysfs interface used on the host. The l3fwd-power application will use this implementation when deployed on a VM - (see Chapter 11 "L3 Forwarding with Power Management Application"). + (see :doc:`l3_forward_power_man`). .. _figure_vm_power_mgr_highlevel: @@ -314,7 +314,7 @@ Manual control and inspection can also be carried in relation CPU frequency scal Compiling and Running the Guest Applications -For compiling and running l3fwd-power, see Chapter 11 "L3 Forwarding with Power Management Application". +For compiling and running l3fwd-power, see :doc:`l3_forward_power_man`. A guest CLI is also provided for validating the setup. -- 1.9.1
[dpdk-dev] [PATCH 12/19] doc: fix l3fwd access control sample app hard-coded references
Signed-off-by: Mauricio Vasquez B --- doc/guides/sample_app_ug/l3_forward_access_ctrl.rst | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/doc/guides/sample_app_ug/l3_forward_access_ctrl.rst b/doc/guides/sample_app_ug/l3_forward_access_ctrl.rst index dbf47c7..4049e01 100644 --- a/doc/guides/sample_app_ug/l3_forward_access_ctrl.rst +++ b/doc/guides/sample_app_ug/l3_forward_access_ctrl.rst @@ -51,8 +51,7 @@ When packets are received from a port, the application extracts the necessary information from the TCP/IP header of the received packet and performs a lookup in the rule database to figure out whether the packets should be dropped (in the ACL range) or forwarded to desired ports. -The initialization and run-time paths are similar to those of the L3 forwarding application -(see Chapter 10, "L3 Forwarding Sample Application" for more information). +The initialization and run-time paths are similar to those of the :doc:`l3_forward`. However, there are significant differences in the two applications. For example, the original L3 forwarding application uses either LPM or an exact match algorithm to perform forwarding port lookup, @@ -360,8 +359,7 @@ Explanation --- The following sections provide some explanation of the sample application code. -The aspects of port, device and CPU configuration are similar to those of the L3 forwarding application -(see Chapter 10, "L3 Forwarding Sample Application" for more information). +The aspects of port, device and CPU configuration are similar to those of the :doc:`l3_forward`. The following sections describe aspects that are specific to L3 forwarding with access control. Parse Rules from File -- 1.9.1
[dpdk-dev] [PATCH 18/19] doc: fix vmdq and dcb fwd sample app hard-coded references
Signed-off-by: Mauricio Vasquez B --- doc/guides/sample_app_ug/vmdq_dcb_forwarding.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/doc/guides/sample_app_ug/vmdq_dcb_forwarding.rst b/doc/guides/sample_app_ug/vmdq_dcb_forwarding.rst index 9140a22..e9ced9f 100644 --- a/doc/guides/sample_app_ug/vmdq_dcb_forwarding.rst +++ b/doc/guides/sample_app_ug/vmdq_dcb_forwarding.rst @@ -77,7 +77,7 @@ To have the application display the statistics, send a SIGHUP signal to the runn where, is the process id of the application process. The VMDQ and DCB Forwarding sample application is in many ways simpler than the L2 Forwarding application -(see Chapter 9 , "L2 Forwarding Sample Application (in Real and Virtualized Environments)") +(see :doc:`l2_forward_real_virtual`) as it performs unidirectional L2 forwarding of packets from one port to a second port. No command-line options are taken by this application apart from the standard EAL command-line options. @@ -132,7 +132,7 @@ Initialization The EAL, driver and PCI configuration is performed largely as in the L2 Forwarding sample application, as is the creation of the mbuf pool. -See Chapter 9, "L2 Forwarding Sample Application (in Real and Virtualized Environments)". +See :doc:`l2_forward_real_virtual`. Where this example application differs is in the configuration of the NIC port for RX. The VMDQ and DCB hardware feature is configured at port initialization time by setting the appropriate values in the @@ -228,7 +228,7 @@ so the pools parameter in the rte_eth_vmdq_dcb_conf structure is specified as a Once the network port has been initialized using the correct VMDQ and DCB values, the initialization of the port's RX and TX hardware rings is performed similarly to that in the L2 Forwarding sample application. -See Chapter 9, "L2 Forwarding Sample Application (in Real and Virtualized Environments)" for more information. +See :doc:`l2_forward_real_virtual` for more information. Statistics Display ~~ -- 1.9.1
[dpdk-dev] [PATCH 15/19] doc: fix link status int sample app hard-coded references
Signed-off-by: Mauricio Vasquez B --- doc/guides/sample_app_ug/link_status_intr.rst | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/doc/guides/sample_app_ug/link_status_intr.rst b/doc/guides/sample_app_ug/link_status_intr.rst index de0dff8..a4dbb54 100644 --- a/doc/guides/sample_app_ug/link_status_intr.rst +++ b/doc/guides/sample_app_ug/link_status_intr.rst @@ -118,16 +118,16 @@ Command Line Arguments ~~ The Link Status Interrupt sample application takes specific parameters, -in addition to Environment Abstraction Layer (EAL) arguments (see Section 13.3). +in addition to Environment Abstraction Layer (EAL) arguments (see Section `Running the Application`_). Command line parsing is done in the same way as it is done in the L2 Forwarding Sample Application. -See Section 9.4.1, "Command Line Arguments" for more information. +See :ref:`l2_fwd_app_cmd_arguments` for more information. Mbuf Pool Initialization Mbuf pool initialization is done in the same way as it is done in the L2 Forwarding Sample Application. -See Section 9.4.2, "Mbuf Pool Initialization" for more information. +See :ref:`l2_fwd_app_mbuf_init` for more information. Driver Initialization ~ @@ -287,7 +287,7 @@ The list of queues that must be polled for a given lcore is stored in a private struct lcore_queue_conf lcore_queue_conf[RTE_MAX_LCORE]; The n_rx_port and rx_port_list[] fields are used in the main packet processing loop -(see Section 13.4.7, "Receive, Process and Transmit Packets" later in this chapter). +(see `Receive, Process and Transmit Packets`_). The global configuration for the RX queues is stored in a static structure: -- 1.9.1
[dpdk-dev] [PATCH 16/19] doc: fix multi-process sample app hard-coded references
Signed-off-by: Mauricio Vasquez B --- doc/guides/sample_app_ug/multi_process.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/guides/sample_app_ug/multi_process.rst b/doc/guides/sample_app_ug/multi_process.rst index 6c3f3d2..ffe7ee6 100644 --- a/doc/guides/sample_app_ug/multi_process.rst +++ b/doc/guides/sample_app_ug/multi_process.rst @@ -378,7 +378,7 @@ using the local cache mechanism of mempool structures. This application performs the same functionality as the L2 Forwarding sample application, therefore this chapter does not cover that part but describes functionality that is introduced in this multi-process example only. -Please refer to Chapter 9, "L2 Forwarding Sample Application (in Real and Virtualized Environments)" for more information. +Please refer to :doc:`l2_forward_real_virtual` for more information. Unlike previous examples where all processes are started from the command line with input arguments, in this example, only one process is spawned from the command line and that process creates other processes. @@ -464,7 +464,7 @@ Therefore, to provide the capability to resume the new slave instance if the pre #. Set up a notification mechanism for slave process exit cases. After the specific slave leaves, the master should be notified and then help to create a new instance. -This mechanism is provided in Section 15.1.5.1, "Master-slave Process Models". +This mechanism is provided in Section `Master-slave Process Models`_. #. Use a synchronization mechanism among dependent processes. The master should have the capability to stop or kill slave processes that have a dependency on the one that has exited. -- 1.9.1
[dpdk-dev] [PATCH 17/19] doc: fix tep termination sample app hard-coded references
Signed-off-by: Mauricio Vasquez B --- doc/guides/sample_app_ug/tep_termination.rst | 8 doc/guides/sample_app_ug/vhost.rst | 7 +++ 2 files changed, 11 insertions(+), 4 deletions(-) diff --git a/doc/guides/sample_app_ug/tep_termination.rst b/doc/guides/sample_app_ug/tep_termination.rst index 71a4acd..2d86a03 100644 --- a/doc/guides/sample_app_ug/tep_termination.rst +++ b/doc/guides/sample_app_ug/tep_termination.rst @@ -121,7 +121,7 @@ The example in this section have been validated with the following distributions Prerequisites - -Refer to the guide in section 27.4 in the vhost sample. +Refer to :ref:`vhost_app_prerequisites`. Compiling the Sample Code - @@ -225,7 +225,7 @@ Parameters **The same parameters with the vhost sample.** -Refer to the guide in section 27.6.1 in the vhost sample for the meanings of 'Basename', +Refer to :ref:`vhost_app_parameters` for the meanings of 'Basename', 'Stats', 'RX Retry', 'RX Retry Number' and 'RX Retry Delay Time'. **Number of Devices.** @@ -303,12 +303,12 @@ The default value is 1. Running the Virtual Machine (QEMU) -- -Refer to the guide in section 27.7 in the vhost sample. +Refer to :ref:`vhost_app_running`. Running DPDK in the Virtual Machine --- -Refer to the guide in section 27.8 in the vHost sample. +Refer to :ref:`vhost_app_running_dpdk`. Passing Traffic to the Virtual Machine Device - diff --git a/doc/guides/sample_app_ug/vhost.rst b/doc/guides/sample_app_ug/vhost.rst index 751656c..47ce36c 100644 --- a/doc/guides/sample_app_ug/vhost.rst +++ b/doc/guides/sample_app_ug/vhost.rst @@ -144,6 +144,8 @@ The example in this section have been validated with the following distributions * Fedora* 20 +.. _vhost_app_prerequisites: + Prerequisites - @@ -405,6 +407,8 @@ Running the Sample Code The number used with the --socket-mem parameter may need to be more than 1024. The number required depends on the number of mbufs allocated by vhost-switch. +.. _vhost_app_parameters: + Parameters ~~ @@ -530,6 +534,8 @@ It is enabled by default. ./vhost-switch -c f -n 4 --socket-mem 1024 --huge-dir /mnt/huge \ -- --vlan-strip [0, 1] +.. _vhost_app_running: + Running the Virtual Machine (QEMU) -- @@ -760,6 +766,7 @@ Common Issues Linux module but which is necessary for the user space VHOST current implementation (CUSE-based) to communicate with the guest. +.. _vhost_app_running_dpdk: Running DPDK in the Virtual Machine --- -- 1.9.1
[dpdk-dev] [PATCH v3 01/12] ethdev: add API to query packet type filling info
> -Original Message-
> From: Tan, Jianfeng
> Sent: Thursday, February 25, 2016 4:36 PM
> To: Ananyev, Konstantin; dev at dpdk.org
> Cc: Zhang, Helin; nelio.laranjeiro at 6wind.com; adrien.mazarguil at
> 6wind.com; rahul.lakkireddy at chelsio.com
> Subject: Re: [PATCH v3 01/12] ethdev: add API to query packet type filling
> info
>
> Hi Konstantin,
>
> On 2/25/2016 11:46 PM, Ananyev, Konstantin wrote:
> > Hi Jainfeng,
> >
> >> Add a new API rte_eth_dev_get_ptype_info to query whether/what packet
> >> type can be filled by given pmd rx burst function.
> >>
> >> Signed-off-by: Jianfeng Tan
> >> ---
> >> lib/librte_ether/rte_ethdev.c | 32
> >> lib/librte_ether/rte_ethdev.h | 23 +++
> >> 2 files changed, 55 insertions(+)
> >>
> >> diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
> >> index 1257965..b52555b 100644
> >> --- a/lib/librte_ether/rte_ethdev.c
> >> +++ b/lib/librte_ether/rte_ethdev.c
> >> @@ -1576,6 +1576,38 @@ rte_eth_dev_info_get(uint8_t port_id, struct
> >> rte_eth_dev_info *dev_info)
> >>dev_info->driver_name = dev->data->drv_name;
> >> }
> >>
> >> +int
> >> +rte_eth_dev_get_ptype_info(uint8_t port_id, uint32_t ptype_mask,
> >> + uint32_t **p_ptypes)
> >> +{
> >> + int i, j, ret;
> >> + struct rte_eth_dev *dev;
> >> + const uint32_t *all_ptypes;
> >> +
> >> + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> >> + dev = &rte_eth_devices[port_id];
> >> + RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_ptype_info_get, -ENOTSUP);
> >> + all_ptypes = (*dev->dev_ops->dev_ptype_info_get)(dev);
> >> +
> >> + if (!all_ptypes)
> >> + return 0;
> >> +
> >> + for (i = 0, ret = 0; all_ptypes[i] != RTE_PTYPE_UNKNOWN; ++i)
> >> + if (all_ptypes[i] & ptype_mask)
> >> + ret++;
> >> + if (ret == 0)
> >> + return 0;
> >> +
> >> + *p_ptypes = (uint32_t *)malloc(sizeof(uint32_t) * ret);
> >> + if (*p_ptypes == NULL)
> >> + return -ENOMEM;
> >
> > I thought we all agreed to follow snprintf()-like logic and avoid any
> > memory allocations inside that function.
> > So why malloc() again?
> > Konstantin
> >
>
> Sorry for the setback. I still have concerns that snprintf()-like needs
> to be called twice by an application to get the ptype info. So I write
> this implementation for you to comment.
>
> So what's the reason why we should avoid memory allocations inside that
> function?
By the same reason none of other rte_ethdev get_info() style functions
(rte_eth_dev_info_get, rte_eth_rx_queue_info_get, rte_eth_xstats_get,
rte_eth_dev_rss_reta_query, etc) allocate space themselves.
It is a good practice to let user to decide himself how/where to allocate/free
a space for that date:
on a stack, inside a data segment (global variable), on heap (malloc),
at hugepages via rte_malloc, somewhere else.
BTW, if you had concerns about that approach, why didn't you provide any
arguments
when it was discussed/agreed?
Instead you came up a month later with same old approach that voids my and other
reviewers comments and even v2 of your own patch.
Do you have any good reason for that?
Konstantin
[dpdk-dev] [PATCH] Updating QAT documentation
Signed-off-by: Fiona Trahe --- doc/guides/cryptodevs/qat.rst | 26 +- 1 file changed, 21 insertions(+), 5 deletions(-) diff --git a/doc/guides/cryptodevs/qat.rst b/doc/guides/cryptodevs/qat.rst index 23402b4..1b4be0c 100644 --- a/doc/guides/cryptodevs/qat.rst +++ b/doc/guides/cryptodevs/qat.rst @@ -1,5 +1,5 @@ .. BSD LICENSE -Copyright(c) 2015 Intel Corporation. All rights reserved. +Copyright(c) 2015-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 @@ -33,9 +33,6 @@ Quick Assist Crypto Poll Mode Driver The QAT PMD provides poll mode crypto driver support for **Intel QuickAssist Technology DH895xxC** hardware accelerator. -The QAT PMD has been tested on Fedora 21 64-bit with gcc and on the 4.4 -kernel.org Linux kernel. - Features @@ -65,7 +62,7 @@ Limitations * Only in-place is currently supported (destination address is the same as source address). * Only supports the session-oriented API implementation (session-less APIs are not supported). * Not performance tuned. - +* No BSD support as BSD QAT kernel driver not available. Installation @@ -197,6 +194,25 @@ the bdf of the 32 VF devices are available per ``DH895xCC`` device. To complete the installation - follow instructions in `Binding the available VFs to the DPDK UIO driver`_. +**Note**: If the QAT kernel modules are not loaded and you see an error like +``Failed to load MMP firmware qat_895xcc_mmp.bin`` this may be as a +result of not using a distribution, but just updating the kernel directly. + +Download firmware from the kernel firmware repo at: +http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/ + +Copy qat binaries to /lib/firmware: +*``cp qat_895xcc.bin /lib/firmware`` +*``cp qat_895xcc_mmp.bin /lib/firmware`` + +cd to your linux source root directory and start the qat kernel modules: +*``insmod ./drivers/crypto/qat/qat_common/intel_qat.ko`` +*``insmod ./drivers/crypto/qat/qat_dh895xcc/qat_dh895xcc.ko`` + +**Note**:The following warning in /var/log/messages can be ignored: +``IOMMU should be enabled for SR-IOV to work correctly`` + + Binding the available VFs to the DPDK UIO driver -- 2.1.0
[dpdk-dev] DPDK-QoS - link sharing across classes
From: sreenaath vasudevan [mailto:sreenaat...@gmail.com]
Sent: Wednesday, February 24, 2016 11:23 PM
To: Dumitrescu, Cristian
Cc: dev at dpdk.org
Subject: Re: [dpdk-dev] DPDK-QoS - link sharing across classes
[Cristian] It does to me, as high priority traffic is usually low bandwidth and
typically fully provisioned (how many voice connections, RTP video conferences,
911 calls, signalling traffic, etc can you have active for a given user at a
given time?), while most of the Internet traffic is best effort (low priority)
and it is typically overprovisioned 20:1 or more.
You can set TC0 rate to 100% of pipe rate, but this is totally not recommended,
because when TC0 demand is exactly 100% you are going to starve the low
priority TC1 .. TC2 completely. You can make Weighted Fair Queuing (WFQ) behave
like strict priority by using big weight ratios like 4:1 or 16:1, but you
cannot make strict priority behave like WFQ (which is what you seem to be
looking for).
>> [Sreenaath] You are right that high priority traffic is usually
>> low-bandwidth. But to me it is no harm to provision un-used link bandwidth
>> to higher priority class. But this is what DPDK provides today and that's
>> fine. But if its possible, I would like to submit to you future feature
>> request for high-priority TC to use un-used bw.
I have another question regarding using only two classes within a pipe. When I
try to provison only two classes TC0 and TC1, then I hit the following code in
"rte_sched_port_check_params() function, which forces me to give some bw to
TC2 and TC3 even if I do not want to use them.
/* TC rate: non-zero, less than pipe rate */
for (j = 0; j < RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE; j ++) {
if ((p->tc_rate[j] == 0) || (p->tc_rate[j] > p->tb_rate)) {
return -12;
}
}
Is there a way around this? How can I provision bw for only two classes TC0 and
TC1 and do not run in to the above issue ?
[Cristian] As you are not using TC2 and TC3, you can probably set any value 0
.. 100% for their rate.
On Wed, Feb 24, 2016 at 3:02 AM, Dumitrescu, Cristian mailto:cristian.dumitrescu at intel.com>> wrote:
From: sreenaath vasudevan [mailto:sreenaathkv at
gmail.com]
Sent: Wednesday, February 24, 2016 12:55 AM
To: Dumitrescu, Cristian mailto:cristian.dumitrescu at intel.com>>
Cc: dev at dpdk.org
Subject: Re: [dpdk-dev] DPDK-QoS - link sharing across classes
b) In current DPDK QoS implemention, if C1 has un-used b/w would that get used
by C0? Or is it only "lower priority class (C3, more specifically) uses the
un-used b/w from higher priority classes (C0,C1,C2) ?
[Cristian] Due to strict priority, it does not make sense to think about higher
priority classes using whatever is not used by low priority classes: If high
priority classes have traffic to send, they will always be picked in the
detriment of lower ones; when the high priority classes hit their upper limit
rate, then they are not allowed to send more, otherwise the upper limit makes
no sense. So the bandwidth reuse concept makes sense only for low prio TCs to
reuse whatever is not used from high prio TCs. Usually, this is configured by
fully provisioning TC0 .. TC2 and setting TC3 to 100% of pipe rate, so TC3 can
use its rate plus whatever gets unused by TC0 .. TC2, so TC3 rate is between:
100% - (rate TC0 + rate TC1 + rate TC2) and 100% of pipe rate. As explained
above, this can be applicable to e.g TC1 as well when only TC0 and TC1 are
actually used. So the answers to your 2 questions are: no/no.
>> Sreenaath - Let's say I have two classes TC0 and TC1 each having a single
>> queue. Let's say I give TC0 60% and TC1 100%. So according to DPDK's
>> implementation, TC1 can use 100% of the bandwidth if TC0 is inactive, while
>> TC0 at any time cannot exceed 60%, even if TC1 is inactive. Is that correct
>> ? And since you mentioned that this is strict priority, according to this
>> implementation, high priority traffic cannot use 100% of the bw even if
>> there is no low priority traffic, but low priority traffic can use 100% of
>> the bw if there is no high priority traffic. Is my understanding correct ?
>> This doesn't make sense.
[Cristian] It does to me, as high priority traffic is usually low bandwidth and
typically fully provisioned (how many voice connections, RTP video conferences,
911 calls, signalling traffic, etc can you have active for a given user at a
given time?), while most of the Internet traffic is best effort (low priority)
and it is typically overprovisioned 20:1 or more.
You can set TC0 rate to 100% of pipe rate, but this is totally not recommended,
because when TC0 demand is exactly 100% you are going to starve the low
priority TC1 .. TC2 completely. You can make Weighted Fair Queuing (WFQ) behave
like strict priority by using big weight ratios like 4:1 or 16:1, but you
cannot make
[dpdk-dev] [PATCH 01/10] ethdev: add a generic flow and new behavior switch to fdir
2016-02-25 15:03, Rahul Lakkireddy:
> On Wednesday, February 02/24/16, 2016 at 14:17:58 -0800, Thomas Monjalon
> wrote:
> > > A raw flow provides a generic way for vendors to add their vendor
> > > specific input flow.
> >
> > Please, "generic" and "vendor specific" in the same sentence.
> > It's obviously wrong.
>
> I think this sentence is being mis-interpreted.
> What I intended to say is: the fields are generic so that any vendor can
> hook-in. The fields themselves are not vendor specific.
We are trying to push some features into fields of an API instead of
thinking how to make it simple.
> > > In our case, it is possible to match several flows
> > > in a single rule. For example, it's possible to set an ethernet, vlan,
> > > ip and tcp/udp flows all in a single rule. We can specify all of these
> > > flows in a single raw input flow, which can then be passed to cxgbe flow
> > > director to set the corresponding filter.
> >
> > I feel we need to define what is an API.
> > If the application wants to call something specific to the NIC, why using
> > the ethdev API? You just have to include cxgbe.h.
>
> Well, in that sense, flow-director is also very intel specific, no ?
Yes. I think the term "flow director" comes from Intel.
> What we are trying to do is make flow-director generic
So let's stop calling it flow director.
We are talking about filtering, right?
> and, we have been
> following the review comments on this. If there are better ideas on how
> to achieve this, we are open to suggestions/comments and are ready to
> re-do the series and re-submit also.
My first question: are you happy with the current API?
Do you understand the difference between RTE_ETH_FILTER_ETHERTYPE and
RTE_ETH_FILTER_FDIR with RTE_ETH_FLOW_L2_PAYLOAD?
Do you understand this structure?
enum rte_eth_fdir_status {
RTE_ETH_FDIR_NO_REPORT_STATUS = 0, /**< Report nothing. */
RTE_ETH_FDIR_REPORT_ID,/**< Only report FD ID. */
RTE_ETH_FDIR_REPORT_ID_FLEX_4, /**< Report FD ID and 4 flex bytes. */
RTE_ETH_FDIR_REPORT_FLEX_8,/**< Report 8 flex bytes. */
};
These values?
enum rte_fdir_mode {
RTE_FDIR_MODE_NONE = 0, /**< Disable FDIR support. */
RTE_FDIR_MODE_SIGNATURE, /**< Enable FDIR signature filter mode. */
RTE_FDIR_MODE_PERFECT, /**< Enable FDIR perfect filter mode. */
RTE_FDIR_MODE_PERFECT_MAC_VLAN, /**< Enable FDIR filter mode - MAC VLAN. */
RTE_FDIR_MODE_PERFECT_TUNNEL, /**< Enable FDIR filter mode - tunnel. */
};
>From my point of view, it is insane.
We have put the hardware complexity in the API.
And now you want to put some vendor specific data in some fields
like some black magic recipes.
Why is it so complex? We are talking about packet filtering, not rocket science!
> > I know the support of filters among NICs is really heterogeneous.
> > And the DPDK API are not yet generic enough. But please do not give up!
> > If the filtering API can be improved to support your cases, please do it.
>
> I am not giving up. If there are better suggestions then, I am willing
> to re-do and re-submit the series.
> If the approach taken in RFC v1 series looks more promising then, I can
> re-surrect that also. However, I will need some direction over here so
> that it becomes generic and doesn't remain intel specific as it is now.
Yes the approach in the RFC was better in the sense it was describing the
fields. But honestly, I'd prefer thinking of filtering from scratch.
What is a hardware filter? (note there is no such doc yet)
It matches a packet with some criterias and take an action on it.
Simple.
Now details (it can take weeks or months to list every details).
A hardware implements a subset of the infinite capabilities.
So the API must provide a flag to check a rule/action capability without
really configuring it.
A matching rule must match every criterias or only some of them (AND/OR
operators).
An action is associated to a matching rule.
There can be several matching rules on the same port (Chelsio case?).
Any packet field can be matched (we currently define some of them).
An action can be of different types:
- drop
- switch
- accept in any queue
- accept in a specific queue
Most of the rules give some values to match the fields.
The hash filtering (RSS) specify only some fields and a key to direct
packets in different queues.
Please, Intel, Chelsio and other vendors, tell what is wrong above
and let's start a sane discussion on hardware filtering.
More background:
The current API was designed by Intel when they were the only NIC vendor.
Now that there are 8 vendors with different capabilities and that FPGA should
bring even more capabilities, we should be able to build something more
generic while being usable.
[dpdk-dev] [PATCH 0/8] Various fixes to compile with gcc6
This series brings a number of code cleanups to allow building using gcc6,
with various legitimate warnings being fixed.
In particular, patch 3 ("drivers/net/e1000: Fix missing brackets") should be
checked for correctness (it does not alter any behavior from a functional
standpoint, but it may be required to do so for a correct fix).
Aaron Conole (8):
lpm: Fix pointer aliasing issues
app/test/test: Fix missing brackets
drivers/net/e1000: Fix missing brackets
drivers/net/e1000: Fix missing lsc interrupt check brackets
drivers/net/ixgbe: Fix vlan filter missing brackets
drivers/net/e1000/igb: Signed left shift operator
drivers/net/ixgbe: Signed left shift operator
drivers/net/ixgbe: Fix uninitialized warning
app/test/test.c| 3 ++-
drivers/net/e1000/base/e1000_phy.c | 12 -
drivers/net/e1000/em_ethdev.c | 3 ++-
drivers/net/e1000/igb_pf.c | 4 +--
drivers/net/ixgbe/ixgbe_ethdev.c | 3 ++-
drivers/net/ixgbe/ixgbe_pf.c | 4 +--
drivers/net/ixgbe/ixgbe_rxtx.c | 4 +--
lib/librte_lpm/rte_lpm.h | 53 +-
8 files changed, 59 insertions(+), 27 deletions(-)
--
2.5.0
[dpdk-dev] [PATCH 1/8] lpm: Fix pointer aliasing issues
The current implementation attempts to use a uint16_t to alias the lpm table
structures. Such aliasing can break optimizer performance. This patch uses
union type indirection and adds static inline functions for performing the
aliasing.
Signed-off-by: Aaron Conole
---
lib/librte_lpm/rte_lpm.h | 53 +---
1 file changed, 41 insertions(+), 12 deletions(-)
diff --git a/lib/librte_lpm/rte_lpm.h b/lib/librte_lpm/rte_lpm.h
index c299ce2..eae6ff1 100644
--- a/lib/librte_lpm/rte_lpm.h
+++ b/lib/librte_lpm/rte_lpm.h
@@ -157,6 +157,33 @@ struct rte_lpm {
};
/**
+ * Convert from tbl_entry types to integer types
+ */
+static inline uint16_t
+rte_lpm_tbl24_entry_to_uint16(const struct rte_lpm_tbl24_entry *entry)
+{
+ union {
+ uint16_t i;
+ struct rte_lpm_tbl24_entry s;
+ } tbl_entry_u;
+
+ tbl_entry_u.s = *entry;
+ return tbl_entry_u.i;
+}
+
+static inline uint16_t
+rte_lpm_tbl8_entry_to_uint16(const struct rte_lpm_tbl8_entry *entry)
+{
+ union {
+ uint16_t i;
+ struct rte_lpm_tbl8_entry s;
+ } tbl_entry_u;
+
+ tbl_entry_u.s = *entry;
+ return tbl_entry_u.i;
+}
+
+/**
* Create an LPM object.
*
* @param name
@@ -286,7 +313,7 @@ rte_lpm_lookup(struct rte_lpm *lpm, uint32_t ip, uint8_t
*next_hop)
RTE_LPM_RETURN_IF_TRUE(((lpm == NULL) || (next_hop == NULL)), -EINVAL);
/* Copy tbl24 entry */
- tbl_entry = *(const uint16_t *)&lpm->tbl24[tbl24_index];
+ tbl_entry = rte_lpm_tbl24_entry_to_uint16(&lpm->tbl24[tbl24_index]);
/* Copy tbl8 entry (only if needed) */
if (unlikely((tbl_entry & RTE_LPM_VALID_EXT_ENTRY_BITMASK) ==
@@ -295,7 +322,7 @@ rte_lpm_lookup(struct rte_lpm *lpm, uint32_t ip, uint8_t
*next_hop)
unsigned tbl8_index = (uint8_t)ip +
((uint8_t)tbl_entry *
RTE_LPM_TBL8_GROUP_NUM_ENTRIES);
- tbl_entry = *(const uint16_t *)&lpm->tbl8[tbl8_index];
+ tbl_entry =
rte_lpm_tbl8_entry_to_uint16(&lpm->tbl8[tbl8_index]);
}
*next_hop = (uint8_t)tbl_entry;
@@ -342,7 +369,8 @@ rte_lpm_lookup_bulk_func(const struct rte_lpm *lpm, const
uint32_t * ips,
for (i = 0; i < n; i++) {
/* Simply copy tbl24 entry to output */
- next_hops[i] = *(const uint16_t *)&lpm->tbl24[tbl24_indexes[i]];
+ next_hops[i] = rte_lpm_tbl24_entry_to_uint16(
+ &lpm->tbl24[tbl24_indexes[i]]);
/* Overwrite output with tbl8 entry if needed */
if (unlikely((next_hops[i] & RTE_LPM_VALID_EXT_ENTRY_BITMASK) ==
@@ -352,7 +380,8 @@ rte_lpm_lookup_bulk_func(const struct rte_lpm *lpm, const
uint32_t * ips,
((uint8_t)next_hops[i] *
RTE_LPM_TBL8_GROUP_NUM_ENTRIES);
- next_hops[i] = *(const uint16_t
*)&lpm->tbl8[tbl8_index];
+ next_hops[i] = rte_lpm_tbl8_entry_to_uint16(
+ &lpm->tbl8[tbl8_index]);
}
}
return 0;
@@ -419,13 +448,13 @@ rte_lpm_lookupx4(const struct rte_lpm *lpm, __m128i ip,
uint16_t hop[4],
idx = _mm_cvtsi128_si64(i24);
i24 = _mm_srli_si128(i24, sizeof(uint64_t));
- tbl[0] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx];
- tbl[1] = *(const uint16_t *)&lpm->tbl24[idx >> 32];
+ tbl[0] = rte_lpm_tbl24_entry_to_uint16(&lpm->tbl24[(uint32_t)idx]);
+ tbl[1] = rte_lpm_tbl24_entry_to_uint16(&lpm->tbl24[idx >> 32]);
idx = _mm_cvtsi128_si64(i24);
- tbl[2] = *(const uint16_t *)&lpm->tbl24[(uint32_t)idx];
- tbl[3] = *(const uint16_t *)&lpm->tbl24[idx >> 32];
+ tbl[2] = rte_lpm_tbl24_entry_to_uint16(&lpm->tbl24[(uint32_t)idx]);
+ tbl[3] = rte_lpm_tbl24_entry_to_uint16(&lpm->tbl24[idx >> 32]);
/* get 4 indexes for tbl8[]. */
i8.x = _mm_and_si128(ip, mask8);
@@ -446,25 +475,25 @@ rte_lpm_lookupx4(const struct rte_lpm *lpm, __m128i ip,
uint16_t hop[4],
RTE_LPM_VALID_EXT_ENTRY_BITMASK)) {
i8.u32[0] = i8.u32[0] +
(uint8_t)tbl[0] * RTE_LPM_TBL8_GROUP_NUM_ENTRIES;
- tbl[0] = *(const uint16_t *)&lpm->tbl8[i8.u32[0]];
+ tbl[0] = rte_lpm_tbl8_entry_to_uint16(&lpm->tbl8[i8.u32[0]]);
}
if (unlikely((pt >> 16 & RTE_LPM_VALID_EXT_ENTRY_BITMASK) ==
RTE_LPM_VALID_EXT_ENTRY_BITMASK)) {
i8.u32[1] = i8.u32[1] +
(uint8_t)tbl[1] * RTE_LPM_TBL8_GROUP_NUM_ENTRIES;
- tbl[1] = *(const uint16_t *)&lpm->tbl8[i8.u32[1]];
+ tbl[1] = rte_lpm_tbl8_entry_to_uint16(&lpm->tbl8[i8.u32[1]]);
}
if (unlikely((pt >> 32 & RTE_LPM_VALID_EXT_ENTRY_BITMASK) ==
[dpdk-dev] [PATCH 2/8] app/test/test: Fix missing brackets
The test application calls printf(...) with the suite->suite_name argument.
The intent (based on whitespace) in the printf is to check suite->suite_name
first and then apply the printf. This doesn't happen due to missing brackets.
Signed-off-by: Aaron Conole
---
app/test/test.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/app/test/test.c b/app/test/test.c
index f35b304..ccad0e3 100644
--- a/app/test/test.c
+++ b/app/test/test.c
@@ -162,9 +162,10 @@ unit_test_suite_runner(struct unit_test_suite *suite)
int test_success;
unsigned total = 0, executed = 0, skipped = 0, succeeded = 0, failed =
0;
- if (suite->suite_name)
+ if (suite->suite_name) {
printf(" +
--- +\n");
printf(" + Test Suite : %s\n", suite->suite_name);
+ }
if (suite->setup)
if (suite->setup() != 0)
--
2.5.0
[dpdk-dev] [PATCH 3/8] drivers/net/e1000: Fix missing brackets
The register read/write mphy functions have misleading whitespace around
the locked check. This cleanup merely preserves the existing functionality
while improving the ready check.
Signed-off-by: Aaron Conole
---
drivers/net/e1000/base/e1000_phy.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/e1000/base/e1000_phy.c
b/drivers/net/e1000/base/e1000_phy.c
index d43b7ce..8642d38 100644
--- a/drivers/net/e1000/base/e1000_phy.c
+++ b/drivers/net/e1000/base/e1000_phy.c
@@ -4153,13 +4153,13 @@ s32 e1000_read_phy_reg_mphy(struct e1000_hw *hw, u32
address, u32 *data)
*data = E1000_READ_REG(hw, E1000_MPHY_DATA);
/* Disable access to mPHY if it was originally disabled */
- if (locked)
+ if (locked) {
ready = e1000_is_mphy_ready(hw);
if (!ready)
return -E1000_ERR_PHY;
- E1000_WRITE_REG(hw, E1000_MPHY_ADDR_CTRL,
- E1000_MPHY_DIS_ACCESS);
+ }
+ E1000_WRITE_REG(hw, E1000_MPHY_ADDR_CTRL, E1000_MPHY_DIS_ACCESS);
return E1000_SUCCESS;
}
@@ -4218,13 +4218,13 @@ s32 e1000_write_phy_reg_mphy(struct e1000_hw *hw, u32
address, u32 data,
E1000_WRITE_REG(hw, E1000_MPHY_DATA, data);
/* Disable access to mPHY if it was originally disabled */
- if (locked)
+ if (locked) {
ready = e1000_is_mphy_ready(hw);
if (!ready)
return -E1000_ERR_PHY;
- E1000_WRITE_REG(hw, E1000_MPHY_ADDR_CTRL,
- E1000_MPHY_DIS_ACCESS);
+ }
+ E1000_WRITE_REG(hw, E1000_MPHY_ADDR_CTRL, E1000_MPHY_DIS_ACCESS);
return E1000_SUCCESS;
}
--
2.5.0
[dpdk-dev] [PATCH 4/8] drivers/net/e1000: Fix missing lsc interrupt check brackets
The device lsc interupt check has a misleading whitespace around it which
can be improved by adding appropriate braces to the check. Since the ret
variable was checked after previous assignment, this introduces no functional
change.
Signed-off-by: Aaron Conole
---
drivers/net/e1000/em_ethdev.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/e1000/em_ethdev.c b/drivers/net/e1000/em_ethdev.c
index 4a843fe..1d86091 100644
--- a/drivers/net/e1000/em_ethdev.c
+++ b/drivers/net/e1000/em_ethdev.c
@@ -637,13 +637,14 @@ eth_em_start(struct rte_eth_dev *dev)
if (rte_intr_allow_others(intr_handle)) {
/* check if lsc interrupt is enabled */
- if (dev->data->dev_conf.intr_conf.lsc != 0)
+ if (dev->data->dev_conf.intr_conf.lsc != 0) {
ret = eth_em_interrupt_setup(dev);
if (ret) {
PMD_INIT_LOG(ERR, "Unable to setup interrupts");
em_dev_clear_queues(dev);
return ret;
}
+ }
} else {
rte_intr_callback_unregister(intr_handle,
eth_em_interrupt_handler,
--
2.5.0
[dpdk-dev] [PATCH 5/8] drivers/net/ixgbe: Fix vlan filter missing brackets
The ixgbe vlan filter code has an if check with an incorrect whitespace.
Signed-off-by: Aaron Conole
---
drivers/net/ixgbe/ixgbe_ethdev.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 3e6fe86..2e1c3ad 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -4258,10 +4258,11 @@ ixgbe_set_pool_vlan_filter(struct rte_eth_dev *dev,
uint16_t vlan,
if (ixgbe_vmdq_mode_check(hw) < 0)
return -ENOTSUP;
for (pool_idx = 0; pool_idx < ETH_64_POOLS; pool_idx++) {
- if (pool_mask & ((uint64_t)(1ULL << pool_idx)))
+ if (pool_mask & ((uint64_t)(1ULL << pool_idx))) {
ret = hw->mac.ops.set_vfta(hw,vlan,pool_idx,vlan_on);
if (ret < 0)
return ret;
+ }
}
return ret;
--
2.5.0
[dpdk-dev] [PATCH 6/8] drivers/net/e1000/igb: Signed left shift operator
Tell the compiler to use an unsigned constant for the config shifts. Signed-off-by: Aaron Conole --- drivers/net/e1000/igb_pf.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/e1000/igb_pf.c b/drivers/net/e1000/igb_pf.c index 1d00dda..afe80f5 100644 --- a/drivers/net/e1000/igb_pf.c +++ b/drivers/net/e1000/igb_pf.c @@ -172,8 +172,8 @@ int igb_pf_host_configure(struct rte_eth_dev *eth_dev) E1000_WRITE_REG(hw, E1000_VT_CTL, vtctl); /* Enable pools reserved to PF only */ - E1000_WRITE_REG(hw, E1000_VFRE, (~0) << vf_num); - E1000_WRITE_REG(hw, E1000_VFTE, (~0) << vf_num); + E1000_WRITE_REG(hw, E1000_VFRE, (~0U) << vf_num); + E1000_WRITE_REG(hw, E1000_VFTE, (~0U) << vf_num); /* PFDMA Tx General Switch Control Enables VMDQ loopback */ if (hw->mac.type == e1000_i350) -- 2.5.0
[dpdk-dev] [PATCH 7/8] drivers/net/ixgbe: Signed left shift operator
Tell the compiler to use an unsigned constant for the config shifts. Signed-off-by: Aaron Conole --- drivers/net/ixgbe/ixgbe_pf.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/ixgbe/ixgbe_pf.c b/drivers/net/ixgbe/ixgbe_pf.c index 2ffbd1f..8b5119f 100644 --- a/drivers/net/ixgbe/ixgbe_pf.c +++ b/drivers/net/ixgbe/ixgbe_pf.c @@ -236,9 +236,9 @@ int ixgbe_pf_host_configure(struct rte_eth_dev *eth_dev) vfre_slot = (vf_num >> VFRE_SHIFT) > 0 ? 1 : 0; /* Enable pools reserved to PF only */ - IXGBE_WRITE_REG(hw, IXGBE_VFRE(vfre_slot), (~0) << vfre_offset); + IXGBE_WRITE_REG(hw, IXGBE_VFRE(vfre_slot), (~0U) << vfre_offset); IXGBE_WRITE_REG(hw, IXGBE_VFRE(vfre_slot ^ 1), vfre_slot - 1); - IXGBE_WRITE_REG(hw, IXGBE_VFTE(vfre_slot), (~0) << vfre_offset); + IXGBE_WRITE_REG(hw, IXGBE_VFTE(vfre_slot), (~0U) << vfre_offset); IXGBE_WRITE_REG(hw, IXGBE_VFTE(vfre_slot ^ 1), vfre_slot - 1); /* PFDMA Tx General Switch Control Enables VMDQ loopback */ -- 2.5.0
[dpdk-dev] [PATCH 8/8] drivers/net/ixgbe: Fix uninitialized warning
Silence a compiler warning that this variable may be used uninitialized.
Signed-off-by: Aaron Conole
---
drivers/net/ixgbe/ixgbe_rxtx.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c b/drivers/net/ixgbe/ixgbe_rxtx.c
index e95e6b7..775edc7 100644
--- a/drivers/net/ixgbe/ixgbe_rxtx.c
+++ b/drivers/net/ixgbe/ixgbe_rxtx.c
@@ -1563,7 +1563,7 @@ ixgbe_recv_pkts_lro(void *rx_queue, struct rte_mbuf
**rx_pkts, uint16_t nb_pkts,
struct ixgbe_rx_entry *rxe;
struct ixgbe_scattered_rx_entry *sc_entry;
struct ixgbe_scattered_rx_entry *next_sc_entry;
- struct ixgbe_rx_entry *next_rxe;
+ struct ixgbe_rx_entry *next_rxe = NULL;
struct rte_mbuf *first_seg;
struct rte_mbuf *rxm;
struct rte_mbuf *nmb;
@@ -1740,7 +1740,7 @@ next_desc:
* the pointer to the first mbuf at the NEXTP entry in the
* sw_sc_ring and continue to parse the RX ring.
*/
- if (!eop) {
+ if (!eop && next_rxe) {
rxm->next = next_rxe->mbuf;
next_sc_entry->fbuf = first_seg;
goto next_desc;
--
2.5.0
[dpdk-dev] [PATCH] eal: add missing long-options for short option arguments
A number of short options for EAL are missing long options
and this patch adds those missing options.
The missing long options are for:
-c add --coremask
-d add --driver
-l add --corelist
-m add --memsize
-n add --mem-channels
-r add --mem-ranks
-v add --version
Add an alias for --lcores using --lcore-map
Signed-off-by: Keith Wiles
---
doc/guides/testpmd_app_ug/run_app.rst | 16 +++
lib/librte_eal/common/eal_common_options.c | 31 --
lib/librte_eal/common/eal_options.h| 16 +++
3 files changed, 45 insertions(+), 18 deletions(-)
diff --git a/doc/guides/testpmd_app_ug/run_app.rst
b/doc/guides/testpmd_app_ug/run_app.rst
index f605564..753a013 100644
--- a/doc/guides/testpmd_app_ug/run_app.rst
+++ b/doc/guides/testpmd_app_ug/run_app.rst
@@ -38,18 +38,18 @@ The following are the EAL command-line options that can be
used in conjunction w
or any other DPDK application.
See the DPDK Getting Started Guides for more information on these options.
-* ``-c COREMASK``
+* ``-c, --coremask COREMASK``
Set the hexadecimal bitmask of the cores to run on.
-* ``-l CORELIST``
+* ``-l, --corelist CORELIST``
List of cores to run on
The argument format is ``[-c2][,c3[-c4],...]``
where ``c1``, ``c2``, etc are core indexes between 0 and 128.
-* ``--lcores COREMAP``
+* ``--lcores COREMAP or --lcore-map COREMAP``
Map lcore set to physical cpu set
@@ -66,7 +66,7 @@ See the DPDK Getting Started Guides for more information on
these options.
Core ID that is used as master.
-* ``-n NUM``
+* ``-n, --mem-channels NUM``
Set the number of memory channels to use.
@@ -74,7 +74,7 @@ See the DPDK Getting Started Guides for more information on
these options.
Blacklist a PCI devise to prevent EAL from using it. Multiple -b options
are allowed.
-* ``-d LIB.so``
+* ``-d, --driver LIB.so|DIR``
Load an external driver. Multiple -d options are allowed.
@@ -82,15 +82,15 @@ See the DPDK Getting Started Guides for more information on
these options.
Add a PCI device in white list.
-* ``-m MB``
+* ``-m, --memsize MB``
Memory to allocate. See also ``--socket-mem``.
-* ``-r NUM``
+* ``-r, --mem-ranks NUM``
Set the number of memory ranks (auto-detected by default).
-* ``-v``
+* ``-v, --version``
Display the version information on startup.
diff --git a/lib/librte_eal/common/eal_common_options.c
b/lib/librte_eal/common/eal_common_options.c
index 29942ea..cf9801d 100644
--- a/lib/librte_eal/common/eal_common_options.c
+++ b/lib/librte_eal/common/eal_common_options.c
@@ -95,6 +95,14 @@ eal_long_options[] = {
{OPT_VFIO_INTR, 1, NULL, OPT_VFIO_INTR_NUM},
{OPT_VMWARE_TSC_MAP,0, NULL, OPT_VMWARE_TSC_MAP_NUM },
{OPT_XEN_DOM0, 0, NULL, OPT_XEN_DOM0_NUM },
+ {OPT_COREMASK, 1, NULL, OPT_COREMASK_NUM },
+ {OPT_DRIVER,1, NULL, OPT_DRIVER_NUM },
+ {OPT_CORELIST, 1, NULL, OPT_CORELIST_NUM },
+ {OPT_MEM_SIZE, 1, NULL, OPT_MEM_SIZE_NUM },
+ {OPT_MEM_CHANNELS, 1, NULL, OPT_MEM_CHANNELS_NUM },
+ {OPT_MEM_RANKS, 1, NULL, OPT_MEM_RANKS_NUM},
+ {OPT_VERSION, 0, NULL, OPT_VERSION_NUM },
+ {OPT_LCORE_MAP, 1, NULL, OPT_LCORE_MAP_NUM},
{0, 0, NULL, 0}
};
@@ -889,6 +897,7 @@ eal_parse_common_option(int opt, const char *optarg,
conf->log_level = log;
break;
}
+ case OPT_LCORE_MAP_NUM:
case OPT_LCORES_NUM:
if (eal_parse_lcores(optarg) < 0) {
RTE_LOG(ERR, EAL, "invalid parameter for --"
@@ -978,11 +987,13 @@ eal_common_usage(void)
{
printf("[options]\n\n"
"EAL common options:\n"
- " -c COREMASK Hexadecimal bitmask of cores to run on\n"
- " -l CORELIST List of cores to run on\n"
+ " -c, --"OPT_COREMASK" Hexadecimal bitmask of cores to run
on\n"
+ " -l, --"OPT_CORELIST" List of cores to run on\n"
" The argument format is
[-c2][,c3[-c4],...]\n"
" where c1, c2, etc are core indexes
between 0 and %d\n"
- " --"OPT_LCORES" COREMAPMap lcore set to physical cpu set\n"
+ "(ex: 1-3,7,9-10) skipping 4,5,6 and 8
cores.\n"
+ " --"OPT_LCORES" COREMAP\n"
+ " --"OPT_LCORE_MAP" COREMAP Map lcore set to physical cpu set\n"
" The argument format is\n"
"
'[<,lcores[@cpus]>...]'\n"
" lcores and cpus list are grouped by '('
and ')'\n"
@@ -991,9 +1002,9 @@ eal_c
[dpdk-dev] [PATCH v6] cfgfile: support looking up sections by index
This is useful when sections have duplicate names.
Signed-off-by: Rich Lane
---
v5->v6:
- Reordered sectionname argument in comment.
v4->v5:
- Reordered sectionname argument.
v3->v4:
- Added section name return value.
- Updated API docs for other functions.
v2->v3
- Added check for index < 0.
v1->v2:
- Added new symbol to version script.
lib/librte_cfgfile/rte_cfgfile.c | 18 ++
lib/librte_cfgfile/rte_cfgfile.h | 39 ++
lib/librte_cfgfile/rte_cfgfile_version.map | 6 +
3 files changed, 63 insertions(+)
diff --git a/lib/librte_cfgfile/rte_cfgfile.c b/lib/librte_cfgfile/rte_cfgfile.c
index 1cd523f..75625a2 100644
--- a/lib/librte_cfgfile/rte_cfgfile.c
+++ b/lib/librte_cfgfile/rte_cfgfile.c
@@ -333,6 +333,24 @@ rte_cfgfile_section_entries(struct rte_cfgfile *cfg, const
char *sectionname,
return i;
}
+int
+rte_cfgfile_section_entries_by_index(struct rte_cfgfile *cfg, int index,
+ char *sectionname,
+ struct rte_cfgfile_entry *entries, int max_entries)
+{
+ int i;
+ const struct rte_cfgfile_section *sect;
+
+ if (index < 0 || index >= cfg->num_sections)
+ return -1;
+
+ sect = cfg->sections[index];
+ snprintf(sectionname, CFG_NAME_LEN, "%s", sect->name);
+ for (i = 0; i < max_entries && i < sect->num_entries; i++)
+ entries[i] = *sect->entries[i];
+ return i;
+}
+
const char *
rte_cfgfile_get_entry(struct rte_cfgfile *cfg, const char *sectionname,
const char *entryname)
diff --git a/lib/librte_cfgfile/rte_cfgfile.h b/lib/librte_cfgfile/rte_cfgfile.h
index d443782..834f828 100644
--- a/lib/librte_cfgfile/rte_cfgfile.h
+++ b/lib/librte_cfgfile/rte_cfgfile.h
@@ -126,6 +126,9 @@ int rte_cfgfile_has_section(struct rte_cfgfile *cfg, const
char *sectionname);
/**
* Get number of entries in given config file section
*
+* If multiple sections have the given name this function operates on the
+* first one.
+*
* @param cfg
* Config file
* @param sectionname
@@ -138,6 +141,9 @@ int rte_cfgfile_section_num_entries(struct rte_cfgfile *cfg,
/** Get section entries as key-value pairs
*
+* If multiple sections have the given name this function operates on the
+* first one.
+*
* @param cfg
* Config file
* @param sectionname
@@ -155,8 +161,38 @@ int rte_cfgfile_section_entries(struct rte_cfgfile *cfg,
struct rte_cfgfile_entry *entries,
int max_entries);
+/** Get section entries as key-value pairs
+*
+* The index of a section is the same as the index of its name in the
+* result of rte_cfgfile_sections. This API can be used when there are
+* multiple sections with the same name.
+*
+* @param cfg
+* Config file
+* @param index
+* Section index
+* @param sectionname
+* Pre-allocated string of at least CFG_NAME_LEN characters where the
+* section name is stored after successful invocation.
+* @param entries
+* Pre-allocated array of at least max_entries entries where the section
+* entries are stored as key-value pair after successful invocation
+* @param max_entries
+* Maximum number of section entries to be stored in entries array
+* @return
+* Number of entries populated on success, negative error code otherwise
+*/
+int rte_cfgfile_section_entries_by_index(struct rte_cfgfile *cfg,
+ int index,
+ char *sectionname,
+ struct rte_cfgfile_entry *entries,
+ int max_entries);
+
/** Get value of the named entry in named config file section
*
+* If multiple sections have the given name this function operates on the
+* first one.
+*
* @param cfg
* Config file
* @param sectionname
@@ -172,6 +208,9 @@ const char *rte_cfgfile_get_entry(struct rte_cfgfile *cfg,
/** Check if given entry exists in named config file section
*
+* If multiple sections have the given name this function operates on the
+* first one.
+*
* @param cfg
* Config file
* @param sectionname
diff --git a/lib/librte_cfgfile/rte_cfgfile_version.map
b/lib/librte_cfgfile/rte_cfgfile_version.map
index bf6c6fd..f6a27a9 100644
--- a/lib/librte_cfgfile/rte_cfgfile_version.map
+++ b/lib/librte_cfgfile/rte_cfgfile_version.map
@@ -13,3 +13,9 @@ DPDK_2.0 {
local: *;
};
+
+DPDK_2.3 {
+ global:
+
+ rte_cfgfile_section_entries_by_index;
+} DPDK_2.0;
--
1.9.1
[dpdk-dev] [PATCH v6] cfgfile: support looking up sections by index
> -Original Message- > From: Rich Lane [mailto:rich.lane at bigswitch.com] > Sent: Thursday, February 25, 2016 8:43 PM > To: dev at dpdk.org > Cc: Dumitrescu, Cristian ; Panu Matilainen > > Subject: [PATCH v6] cfgfile: support looking up sections by index > > This is useful when sections have duplicate names. > > Signed-off-by: Rich Lane > --- > v5->v6: > - Reordered sectionname argument in comment. Acked-by: Cristian Dumitrescu Thanks, Rich!
[dpdk-dev] [PATCH 1/8] lpm: Fix pointer aliasing issues
On Thu, Feb 25, 2016 at 01:48:34PM -0500, Aaron Conole wrote:
> The current implementation attempts to use a uint16_t to alias the lpm table
> structures. Such aliasing can break optimizer performance. This patch uses
> union type indirection and adds static inline functions for performing the
> aliasing.
>
> Signed-off-by: Aaron Conole
> ---
> lib/librte_lpm/rte_lpm.h | 53
> +---
> 1 file changed, 41 insertions(+), 12 deletions(-)
>
> diff --git a/lib/librte_lpm/rte_lpm.h b/lib/librte_lpm/rte_lpm.h
> index c299ce2..eae6ff1 100644
> --- a/lib/librte_lpm/rte_lpm.h
> +++ b/lib/librte_lpm/rte_lpm.h
> @@ -157,6 +157,33 @@ struct rte_lpm {
> };
>
> /**
> + * Convert from tbl_entry types to integer types
> + */
> +static inline uint16_t
> +rte_lpm_tbl24_entry_to_uint16(const struct rte_lpm_tbl24_entry *entry)
> +{
> + union {
> + uint16_t i;
> + struct rte_lpm_tbl24_entry s;
> + } tbl_entry_u;
> +
> + tbl_entry_u.s = *entry;
> + return tbl_entry_u.i;
> +}
> +
> +static inline uint16_t
> +rte_lpm_tbl8_entry_to_uint16(const struct rte_lpm_tbl8_entry *entry)
> +{
> + union {
> + uint16_t i;
> + struct rte_lpm_tbl8_entry s;
> + } tbl_entry_u;
> +
> + tbl_entry_u.s = *entry;
> + return tbl_entry_u.i;
> +}
> +
These two new functions could be reduced to one with the help of patch:
http://dpdk.org/dev/patchwork/patch/9087/
Anyone care to go back and review or ack that patch for me and simplify all
the lpm code just that little bit?
/Bruce
