On Sun, Sep 10, 2017 at 04:32:19PM +0000, Chandran, Sugesh wrote:
> As mentioned earlier in the cover letter we also have a similar
> implementation to do the flow translate.
> I feel its good to make bit more modular for this translation. The reason
> being its easy to extend and add more protocols in the future.
Honestly, I don't see a strong need to make it that complex first. Yes,
it's a big function with a chunk of codes. And yes, I'm also a fun of
splitting big monsters to many small functions. However, if you look
at it closer, you will see it's nicely organized: the function is split
nicely with chunks: something like one chunk for one protocol.
Extending is also not that hard: just adding another chunk of the code.
Besides, if you see tc offloads, they do it in a same way.
[...]
> > +
> > +/*
> > + * Validate for later rte flow offload creation. If any unsupported
> > + * flow are specified, return -1.
> > + */
> [Sugesh] I feel this is very hardware centric. There are chances hardware can
> support
> Ipv6 or other fields in a packet. This has to be based on what flow fields a
> hardware can support.
Yes, you are right. Again, we need capabilities feedback from DPDK.
--yliu
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
