[dpdk-dev] Flow Director - big endian handling

[dpdk-dev] Flow Director - big endian handling

[Yaacov Hazan]

Hi JingJing,

I looked at your patch for flow director - app/testpmd: update flow director commands - a56335925919d26c81dec8accf31c39d2f790c5a.

It seems there is some mismatch in the handling of big endian between the filter and mask.
In the cmd_flow_director_filter_parsed function, which add the filter values, you called to rte_cpu_to_be_16 for the vlan_tci and ports values.
But in cmd_flow_director_mask_parsed function, which set the mask, you didn't called to rte_cpu_to_be_16 for those values (valn_tci & ports).

Does Intel's NICs (or Intel's PMDs) expected form application side to handle the big endian in different way for the filter values and the mask values?
If yes, it is very confusing from the application/user point of view.
I think that it is more make sense to leave the decision and handling of the big endian to the PMD layer, or at least to keep consistency for the expected handling in the application layer.

Thanks,
Yaacov.

Re: [dpdk-dev] Flow Director - big endian handling

[Wu, Jingjing]

Hi, Yaacov

Thank you for pointing that.

Actually, Intel's NIC expects big endian when set flow_director_filter, and little endian when set flow_director_mask. But in rte_eth level, we need to make them consistent.  I think what you say make sense, to leave the handling bytes order to PMD or just keep consistency.

I will work on that.

Thanks a lot!
Jingjing

From: Yaacov Hazan [mailto:yaacovh@mellanox.com]
Sent: Wednesday, December 30, 2015 5:57 PM
To: Wu, Jingjing
Cc: dev@dpdk.org
Subject: Flow Director - big endian handling

Hi JingJing,

I looked at your patch for flow director - app/testpmd: update flow director commands - a56335925919d26c81dec8accf31c39d2f790c5a.

It seems there is some mismatch in the handling of big endian between the filter and mask.
In the cmd_flow_director_filter_parsed function, which add the filter values, you called to rte_cpu_to_be_16 for the vlan_tci and ports values.
But in cmd_flow_director_mask_parsed function, which set the mask, you didn't called to rte_cpu_to_be_16 for those values (valn_tci & ports).

Does Intel's NICs (or Intel's PMDs) expected form application side to handle the big endian in different way for the filter values and the mask values?
If yes, it is very confusing from the application/user point of view.
I think that it is more make sense to leave the decision and handling of the big endian to the PMD layer, or at least to keep consistency for the expected handling in the application layer.

Thanks,
Yaacov.