On Fri, Jan 11, 2019 at 05:35:45PM +0000, Pieter Jansen van Vuuren wrote:
> On 11/01/2019 16:49, Ben Pfaff wrote:
> > On Fri, Jan 11, 2019 at 11:51:53AM +0000, Pieter Jansen van Vuuren wrote:
> >> +/* These functions specifically help shifting words in network
> >> + * byte order, given that they are specified in host order. */
> >> +static inline uint32_t
> >> +shift_ovs_be32_left(uint32_t word, int shift)
> >> +{
> >> + uint32_t word_shifted = (OVS_FORCE uint32_t)htonl(word) << shift;
> >> +
> >> + return ntohl((OVS_FORCE ovs_be32)word_shifted);
> >> +}
> >> +
> >> +static inline uint32_t
> >> +shift_ovs_be32_right(uint32_t word, int shift)
> >> +{
> >> + uint32_t word_shifted = (OVS_FORCE uint32_t)htonl(word) >> shift;
> >> +
> >> + return ntohl((OVS_FORCE ovs_be32)word_shifted);
> >> +}
> >
> > I don't understand how these new operations make sense. Can you
> > explain?
> >
>
> Sure,
>
> Background:
> The original issue is that pedit performs set action operation per word, and
> the way we are describing the translation from OvS to TC is by using byte
> offsets(flower_pedit_map). However some fields like Traffic Class in IPv6 span
> 2 pedit-words - one nibble of the field is in one word and the other nibble is
> in another word. In order to accommodate this a shift may be used.
>
> We need to do this shift in network order thus we need the conversion from
> host
> to network, but the types for htonl/ntohl either takes as parameter or returns
> ovs_be32. Doing the shift operation on ovs_be32 results in the compiler
> degrades to integer:
>
> error: restricted ovs_be32 degrades to integer
>
> Passing that back to ntohl would result in:
>
> error: incorrect type in argument 1 (different base types)
> expected restricted ovs_be32 [usertype] x
> got unsigned int
>
> therefore we introduced these new operations. Hope this helps. I'm open to
> alternate approaches to this problem.
The part I don't understand is why doing a shift of a word in network
byte order makes any sense. It will have different semantics depending
on whether the host is little-endian or big-endian. Why is that
desirable?
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
