-----Original Message-----
From: <[email protected]> on behalf of Joe Stringer <[email protected]>
Date: Wednesday, July 19, 2017 at 2:54 PM
To: Darrell Ball <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [ovs-dev] [PATCH 2/2] dpif-netdev: Indicate support for various ct 
features.

    On 19 July 2017 at 14:11, Darrell Ball <[email protected]> wrote:
    > On Wed, Jul 19, 2017 at 1:18 PM, Darrell Ball <[email protected]> wrote:
    >> On Wed, Jul 19, 2017 at 12:17 PM, Justin Pettit <[email protected]> wrote:
    >>> > On Jul 19, 2017, at 10:45 AM, Darrell Ball <[email protected]> wrote:
    >>> > On 7/19/17, 8:01 AM, "Justin Pettit" <[email protected]> wrote:
    >>> >> On Jul 19, 2017, at 2:45 AM, Darrell Ball <[email protected]> wrote:
    >>> >> static struct odp_support dp_netdev_support = {
    >>> >>   .max_vlan_headers = SIZE_MAX,
    >>> >>   .max_mpls_depth = SIZE_MAX,
    >>> >>   .recirc = false,
    >>> >>   .ct_state = false,
    >>> >>   .ct_zone = false,
    >>> >>   .ct_mark = false,
    >>> >>   .ct_label = false,
    >>> >>   .ct_state_nat = false,
    >>> >>   .ct_orig_tuple = false,
    >>> >>   .ct_orig_tuple6 = false,
    >>> >> };
    >>> >>
    >>> >> I think it may be better to clean this up. I can do this if you are 
ok
    >>> with that; either way is fine with me.
    >>> >
    >>> >    I agree that since the datapath features are probed, we should pass
    >>> those parameters around instead of using these hardcoded values.  
However,
    >>> it was a more invasive change than I wanted to make at the time, and I'd
    >>> want to apply this fix regardless.  I was going to add using the probed
    >>> values to my to-do list, but I'm happy if you want to take it.
    >>> >
    >>> > If there is a pressing reason to make a temporary fix, then that is
    >>> fine.
    >>>
    >>> This seems like an obvious fix, and can be safely backported to earlier
    >>> version.  I agree that feature-probing is a better long-term solution, 
but
    >>> I'd prefer to backport this rather than a bigger change.  I would have
    >>> proposed this patch anyway.
    >>>
    >>
    >
    > [Darrell] Backporting may not apply here as none of Jarno's original tuple
    > code made it
    >               to 2.7
    > ///////////////
    
    I think that ct_state_nat was there though, so that bit should
    probably be backported.
    __________________________

[Darrell] NAT is not applicable to 2.7 for Userspace.

_____________________
    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=MH9-495CT68FfpGi4AKGJPvMdFdMFBWa8begcqVEjt8&s=TiEwlusIM4xqR6YeTyeLGZ1uF7m_4Va85Z3qZgfHDaE&e=
 
    

_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to