On 6 Jul 2021, at 15:11, Cian Ferriter wrote:
> From: Harry van Haaren <[email protected]>
>
> This commit adds AVX512 implementations of miniflow extract.
> By using the 64 bytes available in an AVX512 register, it is
> possible to convert a packet to a miniflow data-structure in
> a small quantity instructions.
>
> The implementation here probes for Ether()/IP()/UDP() traffic,
> and builds the appropriate miniflow data-structure for packets
> that match the probe.
>
> The implementation here is auto-validated by the miniflow
> extract autovalidator, hence its correctness can be easily
> tested and verified.
>
> Note that this commit is designed to easily allow addition of new
> traffic profiles in a scalable way, without code duplication for
> each traffic profile.
>
> Signed-off-by: Harry van Haaren <[email protected]>
>
> ---
>
> v5:
<SNIP>
> +
> +BUILD_ASSERT_DECL((OFFSETOFEND(struct dp_packet, l4_ofs)
> + - offsetof(struct dp_packet, l2_pad_size)) ==
> + MEMBER_SIZEOF(struct mfex_profile, dp_pkt_offs));
> +
> +/* Any change in flow abi should be inluded here otherwise build should
included
> + * fail.
> + */
> +BUILD_ASSERT_DECL(FLOW_WC_SEQ == 42);
I was discussing this assert offline, and some issues were raised as a lot of
people build on top of OVS, and add new protocols, hence changing the
FLOW_WC_SEQ.
It would be good to add more details on what to change/check before you
increase the value here. For example, which fields in the in mfex_profile
structure, or what changes to the flow structure require changes in the AVX
code.
On top of this, a solution could also be to allow for compile-time disabling of
MFEX for people that do their own hacking of OVS?
Thoughts?
<SNIP>
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
