[dpdk-dev] [PATCH v2 05/13] net/sfc: fix endian conversions in flow API

[Adrien Mazarguil]

Hi Andrew,

On Wed, Apr 04, 2018 at 06:30:24PM +0300, Andrew Rybchenko wrote:
> Adrien,
> 
> On 04/04/2018 05:57 PM, Adrien Mazarguil wrote:
> > These conversions do not use the adequate function.
> > 
> > Fixes: a9825ccf5bb8 ("net/sfc: support flow API filters")
> > Fixes: 894080975e1e ("net/sfc: support VLAN in flow API filters")
> > Fixes: e2675132444e ("net/sfc: support TCP in flow API filters")
> > Fixes: e01f84f42cad ("net/sfc: support UDP in flow API filters")
> > Cc: stable at dpdk.org
> > Cc: Roman Zhukov <roman.zhukov at oktetlabs.ru>
> > Cc: Andrew Rybchenko <arybchenko at solarflare.com>
> > 
> > Signed-off-by: Adrien Mazarguil <adrien.mazarguil at 6wind.com>
> > ---
> >   drivers/net/sfc/sfc_flow.c | 13 +++++++------
> >   1 file changed, 7 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/net/sfc/sfc_flow.c b/drivers/net/sfc/sfc_flow.c
> > index fe4c0b0c5..9060fdc2f 100644
> > --- a/drivers/net/sfc/sfc_flow.c
> > +++ b/drivers/net/sfc/sfc_flow.c
> > @@ -7,6 +7,7 @@
> >    * for Solarflare) and Solarflare Communications, Inc.
> >    */
> > +#include <rte_byteorder.h>
> >   #include <rte_tailq.h>
> >   #include <rte_common.h>
> >   #include <rte_ethdev_driver.h>
> > @@ -315,7 +316,7 @@ sfc_flow_parse_eth(const struct rte_flow_item *item,
> >   	 */
> >   	if (mask->type == supp_mask.type) {
> >   		efx_spec->efs_match_flags |= EFX_FILTER_MATCH_ETHER_TYPE;
> > -		efx_spec->efs_ether_type = rte_bswap16(spec->type);
> > +		efx_spec->efs_ether_type = rte_be_to_cpu_16(spec->type);
> >   	} else if (mask->type != 0) {
> >   		goto fail_bad_mask;
> >   	}
> > @@ -370,7 +371,7 @@ sfc_flow_parse_vlan(const struct rte_flow_item *item,
> >   	 * the outer tag and the next matches the inner tag.
> >   	 */
> >   	if (mask->tci == supp_mask.tci) {
> > -		vid = rte_bswap16(spec->tci);
> > +		vid = rte_be_to_cpu_16(spec->tci);
> >   		if (!(efx_spec->efs_match_flags &
> >   		      EFX_FILTER_MATCH_OUTER_VID)) {
> > @@ -654,14 +655,14 @@ sfc_flow_parse_tcp(const struct rte_flow_item *item,
> >   	 */
> >   	if (mask->hdr.src_port == supp_mask.hdr.src_port) {
> >   		efx_spec->efs_match_flags |= EFX_FILTER_MATCH_REM_PORT;
> > -		efx_spec->efs_rem_port = rte_bswap16(spec->hdr.src_port);
> > +		efx_spec->efs_rem_port = rte_be_to_cpu_16(spec->hdr.src_port);
> >   	} else if (mask->hdr.src_port != 0) {
> >   		goto fail_bad_mask;
> >   	}
> >   	if (mask->hdr.dst_port == supp_mask.hdr.dst_port) {
> >   		efx_spec->efs_match_flags |= EFX_FILTER_MATCH_LOC_PORT;
> > -		efx_spec->efs_loc_port = rte_bswap16(spec->hdr.dst_port);
> > +		efx_spec->efs_loc_port = rte_be_to_cpu_16(spec->hdr.dst_port);
> >   	} else if (mask->hdr.dst_port != 0) {
> >   		goto fail_bad_mask;
> >   	}
> > @@ -735,14 +736,14 @@ sfc_flow_parse_udp(const struct rte_flow_item *item,
> >   	 */
> >   	if (mask->hdr.src_port == supp_mask.hdr.src_port) {
> >   		efx_spec->efs_match_flags |= EFX_FILTER_MATCH_REM_PORT;
> > -		efx_spec->efs_rem_port = rte_bswap16(spec->hdr.src_port);
> > +		efx_spec->efs_rem_port = rte_be_to_cpu_16(spec->hdr.src_port);
> >   	} else if (mask->hdr.src_port != 0) {
> >   		goto fail_bad_mask;
> >   	}
> >   	if (mask->hdr.dst_port == supp_mask.hdr.dst_port) {
> >   		efx_spec->efs_match_flags |= EFX_FILTER_MATCH_LOC_PORT;
> > -		efx_spec->efs_loc_port = rte_bswap16(spec->hdr.dst_port);
> > +		efx_spec->efs_loc_port = rte_be_to_cpu_16(spec->hdr.dst_port);
> >   	} else if (mask->hdr.dst_port != 0) {
> >   		goto fail_bad_mask;
> >   	}
> 
> efs_filter_spec_t members are little-endian (_not_ host-endian). At least
> comments
> say so and to be consistent we use rte_bswap*() functions intentionally.
> Yes, may be it is buggy in fact - I don't know. The code never worked on
> big-endian.
> So, we're aware and thanks for the reminder.
> We'd prefer to keep it as is if there is no strong reasons to change.

I didn't notice those members had to be little endian, I'll drop this patch
from the series and fix subsequent patch [1] accordingly.

Can you have a look at this patch before I roll new version for both series?

Thanks.

[1] http://dpdk.org/ml/archives/dev/2018-April/095311.html

-- 
Adrien Mazarguil
6WIND