Re: [dpdk-dev] L3fwd mode in testpmd

[Stanislaw Kardach <kda@semihalf.com>]

On Thu, Apr 29, 2021 at 11:47:30AM +0000, Ananyev, Konstantin wrote:
<snip>
> > 
> > It looks as if implementing em_mask_key() is enough to get l3fwd
> > working. However to me this ifdef seems tricky. How should a scalar
> > implementation handle the xmm_t type? rte_xmm_t looks like an API
> > type/union, but both are not mentioned in documentation and are in
> > platform dependent rte_vect.h only.
> > So either I add another case for RISC-V or (what seems more proper) add
> > an else clause implementation. However then should I change this function
> > to take rte_xmm_t? If not is casting xmm_t to i.e. int32_t[] always
> > valid? Even if I change to rte_xmm_t, it's not a stable API type, is it?
> > So what guarantee do I have that it maps to int32_t bit-wise on every
> > platform?
> > 
> > I think the semantic requirements of xmm_t typedef are a bit undefined as
> > well as the vector handling across the architectures (being something
> > rather arch specific). I don't have a clear idea on how to solve this
> > yet and I would not like to hijack this discussion with vector stuff.
> > 
> > Though I may be missing some obvious solution here. Any idea is welcome.
> > :)
> 
> I think it should be possible to replace xmm_t with rte_xmm_t in ipv(4|6)_5tuple_host
> and make em_mask_key to take 'rte_xmm_t *' as a parameter/return value instead of xmm_t.
> With that in place scalar version seems straightforward.
> Of course perf regression test would be needed after such changes,
> but I think with '-O3' it should be no difference.
> 
I did that and it works in practice. I'm more asking about the lack of
definition in rte_xmm_t semantics. Because once it's in an example,
people may start assuming it's OK to use it this way.
If it is OK, then I'll just post a patch, otherwise we need a separate
discussion.

-- 
Best Regards,
Stanislaw Kardach