On 9/11/17, 3:02 AM, "ovs-dev-boun...@openvswitch.org on behalf of Yuanhan Liu" 
<ovs-dev-boun...@openvswitch.org on behalf of y...@fridaylinux.org> 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
    d...@openvswitch.org
    
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
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to