On 9/11/17, 3:02 AM, "[email protected] on behalf of Yuanhan Liu"
<[email protected] on behalf of [email protected]> wrote:
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.
[Darrell] There have been several mentions of capability queries in version 1
and version 2 of the patchset.
1/ We asked for HW scaling checks to better support manageability and
predictability.
2/ We asked for a ‘queue action workaround requirement’ query, which would be a
nice enhancement,
to avoid an unnecessary first failed attempt at flow create for nics that
don’t allow the mark action in isolation.
3/ Here we ask for flow matching capability checking, with fallback to what we
already support today.
Similar kinds of queries were also mentioned in regard to the patchset
“prioritizing latency sensitive traffic”.
TCP flags matching mentioned in Patch 2 also falls into this category.
--yliu
_______________________________________________
dev mailing list
[email protected]
https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-uZnsw&m=SbdNOA5djgzhAIm49EWuBLui1KsaSl-tOsvhgb685Js&s=oKRfV8aE2G8A_Te761VR9n29SJuhr4-SJshaFetgICw&e=
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
