DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Legacy, Allain" <Allain.Legacy@windriver.com>
To: "Nelio Laranjeiro (nelio.laranjeiro@6wind.com)"
	<nelio.laranjeiro@6wind.com>,
	"Adrien Mazarguil (adrien.mazarguil@6wind.com)"
	<adrien.mazarguil@6wind.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: [dpdk-dev] mlx5 vxlan match filter vni endianness
Date: Wed, 5 Apr 2017 20:23:35 +0000	[thread overview]
Message-ID: <70A7408C6E1BFB41B192A929744D852396902508@ALA-MBC.corp.ad.wrs.com> (raw)

Hi,
None of the comments in the rte_flow.h file (or the programmers guide) specify what endianness should be applied to spec/mask fields.  Based on the testing I have done so far using a CX4 device (mlx5 driver) fields like VLAN ID and UDP ports are expected in network byte order.  There seems to be a discrepancy with how VXLAN VNI values are expected; at least for this one driver.  Matching only works on VNI if it is specified in host byte order.

/**
* RTE_FLOW_ITEM_TYPE_VXLAN.
*
* Matches a VXLAN header (RFC 7348).
*/
struct rte_flow_item_vxlan {
                uint8_t flags; /**< Normally 0x08 (I flag). */
                uint8_t rsvd0[3]; /**< Reserved, normally 0x000000. */
                uint8_t vni[3]; /**< VXLAN identifier. */
                uint8_t rsvd1; /**< Reserved, normally 0x00. */ };


I have not done any testing on an i40e device yet, but looking at the i40e_flow.c code it looks like that driver expects to receive the VNI in network byte order:

                                if (vxlan_spec && vxlan_mask && !is_vni_masked) {
                                                /* If there's vxlan */
                                                rte_memcpy(((uint8_t *)&tenant_id_be + 1),
                                                                   vxlan_spec->vni, 3);
                                                filter->tenant_id = rte_be_to_cpu_32(tenant_id_be);
                                                if (!o_eth_spec && !o_eth_mask &&


Can you confirm whether the mlx5_flow.c behavior is a bug or whether my understand is incorrect?

Regards,
Allain

Allain Legacy, Software Developer, Wind River
direct 613.270.2279  fax 613.492.7870 skype allain.legacy
350 Terry Fox Drive, Suite 200, Ottawa, Ontario, K2K 2W5

 

             reply	other threads:[~2017-04-05 20:23 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-05 20:23 Legacy, Allain [this message]
2017-04-06 14:43 ` Nélio Laranjeiro
2017-04-06 15:43   ` Legacy, Allain

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=70A7408C6E1BFB41B192A929744D852396902508@ALA-MBC.corp.ad.wrs.com \
    --to=allain.legacy@windriver.com \
    --cc=adrien.mazarguil@6wind.com \
    --cc=dev@dpdk.org \
    --cc=nelio.laranjeiro@6wind.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).