[ovs-dev] [PATCH v2 4/8] netdev-dpdk: implement flow put with rte flow

Darrell Ball dball at vmware.com
Wed Sep 13 03:47:55 UTC 2017



On 9/11/17, 3:02 AM, "ovs-dev-bounces at openvswitch.org on behalf of Yuanhan Liu" <ovs-dev-bounces at openvswitch.org on behalf of yliu at 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
    dev at 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= 
    







More information about the dev mailing list