From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f173.google.com (mail-wr0-f173.google.com [209.85.128.173]) by dpdk.org (Postfix) with ESMTP id F121B1E20 for ; Thu, 6 Apr 2017 16:43:32 +0200 (CEST) Received: by mail-wr0-f173.google.com with SMTP id g19so21803113wrb.0 for ; Thu, 06 Apr 2017 07:43:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=X9wDgexWF+q5pSYLChJq+cuH3cVmo+voGq59LYQWesM=; b=0AttTf1p2QiyB9piGGSiKXe3hAOtmD3rgrbw9shvIb6bIVY57xylvBhkPJgVbgh/S3 /78MI7Y2bnDiql4rkDjQ76gx4TYy76TGfh2HVWg6wSy96/tinECbYtrNTyHsNldLjE9n pV/ccLvkttimsijp6Yq+8fbkJliKekCK6OGz8/PS7QXsxfASyjFa8XiyiU/v21Mogi49 fwJsjIilJIL/W3uyETUX+LDuXnjOhBNyjPdVMLMqXJiEARitS3VUVFt2DEXnf1qgbW0P 6rWKqGrsYLQXRc4DKiteyGndJQ4TQtWxBJ3Rz9R+pYOOQr/IJkS/6erJDYIV1WRLWu9Y viyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=X9wDgexWF+q5pSYLChJq+cuH3cVmo+voGq59LYQWesM=; b=W7cFXoV2GHxaeBeX2rHzvGHb/oqrFpbHLKZOrSj21DFj9HhG9mnNRNDALv1+HY3IqE YRlwXql/TmLcG99lvHL3Ce5iGnPeZXowCVlzkM0KIuYX20QKLou1C5ygoEtjVOCI6WcS VnsCEBYkUMu1wRy3PnUR7fTN4EGHEEhNxY+aijimF8NDRmGPHfIBh/OdM9XGQb3/GYGn 2djQidy3Bri/Vxu+8PPp+vnlwgAd9v/pF9vAqpDw7GDgee+yL8CaYqcXKCU81Pcoz6Wc eSJitHIBlNxXEscWDzgIATyjayPpg9UipGMya8IypP8OOIzPGG0CR23aBdFtOmBtwT7c oXkw== X-Gm-Message-State: AFeK/H2TErnh9d/E10Yf0jd3g5wzrVYdq8ZLW0JtXM0U66E6St2lQXHcKAH+EwO5ZXjXXrZ3 X-Received: by 10.223.164.2 with SMTP id d2mr28934904wra.47.1491489812593; Thu, 06 Apr 2017 07:43:32 -0700 (PDT) Received: from autoinstall.dev.6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id 140sm2700707wmk.12.2017.04.06.07.43.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Apr 2017 07:43:32 -0700 (PDT) Date: Thu, 6 Apr 2017 16:43:23 +0200 From: =?iso-8859-1?Q?N=E9lio?= Laranjeiro To: "Legacy, Allain" Cc: "Adrien Mazarguil (adrien.mazarguil@6wind.com)" , "dev@dpdk.org" Message-ID: <20170406144323.GH16796@autoinstall.dev.6wind.com> References: <70A7408C6E1BFB41B192A929744D852396902508@ALA-MBC.corp.ad.wrs.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <70A7408C6E1BFB41B192A929744D852396902508@ALA-MBC.corp.ad.wrs.com> User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [dpdk-dev] mlx5 vxlan match filter vni endianness X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 14:43:33 -0000 On Wed, Apr 05, 2017 at 08:23:35PM +0000, Legacy, Allain wrote: > 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? Hi Allain, RTE flow always provide the fields in network order, some mistakes was already reported and that was the main reason I proposed to document such types[1]. Your point is correct, the difference in both PMD come from the fact the NIC do not have the same endianess. Intel NIC are little endian whereas Mellanox are big endian, that's why there is no "byteswap" for the VNI in Mellanox PMD. In the doubt I have just tested a flow rule with a VXLAN and VNI value to redirect it to another queue, it work perfectly for me on mlx5. You are facing some kind of issue? Thanks, [1] http://dpdk.org/ml/archives/dev/2016-November/050060.html -- Nélio Laranjeiro 6WIND