[dpdk-dev] [PATCH v2 05/13] net/sfc: fix endian conversions in flow API
Andrew Rybchenko
arybchenko at solarflare.com
Thu Apr 5 17:10:41 CEST 2018
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 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
We're still testing these patches since it requires fixes in test harness.
We'll provide feedback tomorrow.
Thanks,
Andrew.
More information about the dev
mailing list