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

[Andrew Rybchenko <arybchenko@solarflare.com>]

Hi Adrien,

On 04/04/2018 07:08 PM, Adrien Mazarguil wrote:
> 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@dpdk.org
>>> Cc: Roman Zhukov <roman.zhukov@oktetlabs.ru>
>>> Cc: Andrew Rybchenko <arybchenko@solarflare.com>
>>>
>>> Signed-off-by: Adrien Mazarguil <adrien.mazarguil@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

We're still testing these patches since it requires fixes in test harness.
We'll provide feedback tomorrow.

Thanks,
Andrew.