On 30 July 2015 at 12:24, Jesse Gross <je...@nicira.com> wrote:
> On Wed, Jul 29, 2015 at 12:53 PM, Joe Stringer <joestrin...@nicira.com> wrote:
>> diff --git a/.travis.yml b/.travis.yml
>> index 70cc14b..f3236db 100644
>> --- a/.travis.yml
>> +++ b/.travis.yml
>> @@ -12,6 +12,7 @@ env:
>>    - TESTSUITE=1 KERNEL=3.18.1
>>    - TESTSUITE=1 OPTS="--enable-shared"
>>    - BUILD_ENV="-m32" OPTS="--disable-ssl"
>> +  - KERNEL=4.1.3
>>    - KERNEL=4.0.2
>
> I wonder if we should just replace 4.0.2? I don't know if we need to
> check every kernel version and it will increase build times.

Sure, this was on my mind too. Do we have some heuristic to figure out
which kernels to test?

The ones that make the most sense to me would be LTS or those included
in major releases of popular distros. Perhaps the existing selection
of versions is more intentional than I can see, but it looks like a
random scattering to me.

> Can you update the FAQ as well?

Sure.

>> diff --git a/datapath/datapath.h b/datapath/datapath.h
>> index 152d70c..4d1f5af 100644
>> --- a/datapath/datapath.h
>> +++ b/datapath/datapath.h
>>  static inline struct net *ovs_dp_get_net(const struct datapath *dp)
>>  {
>> -       return read_pnet(&dp->net);
>> +       return rpl_read_pnet(&dp->net);
>>  }
>>
>>  static inline void ovs_dp_set_net(struct datapath *dp, struct net *net)
>>  {
>> -       write_pnet(&dp->net, net);
>> +       rpl_write_pnet(&dp->net, net);
>>  }
>
> Can you define macros to handle the rpl_ prefix without needing to
> have it be explicit here?

I'll have a play around with this again; I had some trouble with this
originally.

>> diff --git a/datapath/linux/compat/include/net/net_namespace.h 
>> b/datapath/linux/compat/include/net/net_namespace.h
>> index b7dbfe3..05c48f4 100644
>> --- a/datapath/linux/compat/include/net/net_namespace.h
>> +++ b/datapath/linux/compat/include/net/net_namespace.h
>> @@ -51,4 +51,33 @@ static void rpl_unregister_pernet_gen_##TYPE(struct 
>> rpl_pernet_operations *rpl_p
>>  #define DEFINE_COMPAT_PNET_REG_FUNC(TYPE)
>>  #endif /* 2.6.33 */
>>
>> +#if LINUX_VERSION_CODE < KERNEL_VERSION(4,1,0)
>> +typedef struct {
>> +#ifdef CONFIG_NET_NS
>> +       struct net *net;
>> +#endif
>> +} possible_net_t;
>> +
>> +static inline void rpl_write_pnet(possible_net_t *pnet, struct net *net)
>> +{
>> +#ifdef CONFIG_NET_NS
>> +       pnet->net = net;
>> +#endif
>> +}
>> +
>> +static inline struct net *rpl_read_pnet(const possible_net_t *pnet)
>> +{
>> +#ifdef CONFIG_NET_NS
>> +       return pnet->net;
>> +#else
>> +       return &init_net;
>> +#endif
>> +}
>> +#else /* Linux >= 4.1 */
>> +#define hold_net(x) (x)
>> +#define release_net(x) (x)
>> +#define rpl_read_pnet read_pnet
>> +#define rpl_write_pnet write_pnet
>> +#endif /* Linux >= 4.1 */
>> +
>>  #endif /* net/net_namespace.h wrapper */
>
> Can we just drop use of hold_net()/release_net()? The commit message
> says that they were disabled even on old kernels.

OK, sure.

>> diff --git a/datapath/linux/compat/include/net/udp_tunnel.h 
>> b/datapath/linux/compat/include/net/udp_tunnel.h
>> index 81cb3df..221639a 100644
>> --- a/datapath/linux/compat/include/net/udp_tunnel.h
>> +++ b/datapath/linux/compat/include/net/udp_tunnel.h
>> @@ -4,7 +4,7 @@
>>  #include <linux/version.h>
>>  #include <linux/kconfig.h>
>>
>> -#if LINUX_VERSION_CODE >= KERNEL_VERSION(4,0,0)
>> +#if LINUX_VERSION_CODE >= KERNEL_VERSION(4,1,0)
>>  #include_next <net/udp_tunnel.h>
>>
>>  static inline struct sk_buff *
>> @@ -71,7 +71,8 @@ void rpl_setup_udp_tunnel_sock(struct net *net, struct 
>> socket *sock,
>>
>>  /* Transmit the skb using UDP encapsulation. */
>>  #define udp_tunnel_xmit_skb rpl_udp_tunnel_xmit_skb
>> -int rpl_udp_tunnel_xmit_skb(struct rtable *rt, struct sk_buff *skb,
>> +int rpl_udp_tunnel_xmit_skb(struct rtable *rt,
>> +                           struct sock *sk, struct sk_buff *skb,
>>                             __be32 src, __be32 dst, __u8 tos, __u8 ttl,
>>                             __be16 df, __be16 src_port, __be16 dst_port,
>>                             bool xnet, bool nocheck);
>
> I think it's probably not a great idea to keep on bumping up the
> version number for which we use our own backports since it would be
> preferable to use the kernel implementation where we can. Can we make
> the version check a little more granular?

OK.

> Looking at the list of commits to 4.1, I see a couple that weren't included:
> netlink: implement nla_put_in_addr and nla_put_in6_addr
> netlink: implement nla_get_in_addr and nla_get_in6_addr
> openvswitch: disable LRO
>
> Can you check these and also see if there are any others?

Sure thing. I'll comb back over and look for others I've missed.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Reply via email to