Re: [PATCH RFC net-next] openvswitch: Queue upcalls to userspace in per-port round-robin order

On Wed, Sep 26, 2018 at 2:58 AM Stefano Brivio wrote: > > Hi Pravin, > > On Wed, 15 Aug 2018 00:19:39 -0700 > Pravin Shelar wrote: > > > I understand fairness has cost, but we need to find right balance > > between performance and fairness. Current fairness sche

Re: [PATCH] [PATCH net-next] openvswitch: Use correct reply values in datapath and vport ops

On Wed, Sep 26, 2018 at 11:40 AM Yifeng Sun wrote: > > This patch fixes the bug that all datapath and vport ops are returning > wrong values (OVS_FLOW_CMD_NEW or OVS_DP_CMD_NEW) in their replies. > > Signed-off-by: Yifeng Sun I am surprised this was not found earlier. Acked-by: Pravin B Shelar

Re: [PATCH net-next v2] openvswitch: Derive IP protocol number for IPv6 later frags

On Tue, Sep 4, 2018 at 3:37 PM Yi-Hung Wei wrote: > > Currently, OVS only parses the IP protocol number for the first > IPv6 fragment, but sets the IP protocol number for the later fragments > to be NEXTHDF_FRAGMENT. This patch tries to derive the IP protocol > number for the IPV6 later frags so

Re: [PATCH] datapath.c: fix missing return value check of nla_nest_start()

On Tue, Aug 21, 2018 at 4:38 PM David Miller wrote: > > From: Pravin Shelar > Date: Tue, 21 Aug 2018 15:38:28 -0700 > > > On Fri, Aug 17, 2018 at 1:15 AM Jiecheng Wu wrote: > >> > >> Function queue_userspace_packet() defined in net/openvswitch/datapath.c >

Re: [PATCH] datapath.c: fix missing return value check of nla_nest_start()

On Fri, Aug 17, 2018 at 1:15 AM Jiecheng Wu wrote: > > Function queue_userspace_packet() defined in net/openvswitch/datapath.c calls > nla_nest_start() to allocate memory for struct nlattr which is dereferenced > immediately. As nla_nest_start() may return NULL on failure, this code piece >

Re: [PATCH RFC net-next] openvswitch: Queue upcalls to userspace in per-port round-robin order

Hi Stefano On Tue, Aug 7, 2018 at 6:31 AM, Stefano Brivio wrote: > Hi Pravin, > > On Tue, 31 Jul 2018 16:12:03 -0700 > Pravin Shelar wrote: > >> Rather than reducing number of thread down to 1, we could find better >> number of FDs per port. >> How about this s

Re: [PATCH net-next] openvswitch: Derive IP protocol number for IPv6 later frags

On Fri, Aug 10, 2018 at 10:19 AM, Yi-Hung Wei wrote: > Currently, OVS only parses the IP protocol number for the first > IPv6 fragment, but sets the IP protocol number for the later fragments > to be NEXTHDF_FRAGMENT. This patch tries to derive the IP protocol > number for the IPV6 later frags

Re: [PATCH RFC net-next] openvswitch: Queue upcalls to userspace in per-port round-robin order

On Tue, Jul 31, 2018 at 12:43 PM, Matteo Croce wrote: > On Mon, Jul 16, 2018 at 4:54 PM Matteo Croce wrote: >> >> On Tue, Jul 10, 2018 at 6:31 PM Pravin Shelar wrote: >> > >> > On Wed, Jul 4, 2018 at 7:23 AM, Matteo Croce wrote: >> > > From: Ste

Re: [PATCH][net-next] openvswitch: eliminate cpu_used_mask from sw_flow

On Fri, Jul 27, 2018 at 1:03 AM, Li RongQing wrote: > The size of struct cpumask varies with CONFIG_NR_CPUS, some config > CONFIG_NR_CPUS is very larger, like 5120, struct cpumask will take > 640 bytes, if there is thousands of flows, it will take lots of > memory > I am fine with removing

Re: [PATCH net 2/2] openvswitch: check for null return for nla_nest_start in datapath

On Wed, Jul 18, 2018 at 9:12 AM, Stephen Hemminger wrote: > The call to nla_nest_start when forming packet messages can lead to a NULL > return so it's possible for attr to become NULL and we can potentially > get a NULL pointer dereference on attr. Fix this by checking for > a NULL return. > >

Re: [PATCH net 1/2] openvswitch: check for null return for nla_nest_start

On Wed, Jul 18, 2018 at 9:12 AM, Stephen Hemminger wrote: > The call to nla_nest_start in conntrack can lead to a NULL > return so it's possible for attr to become NULL and we can potentially > get a NULL pointer dereference on attr. Fix this by checking for > a NULL return. > > Bugzilla:

Re: [PATCH RFC net-next] openvswitch: Queue upcalls to userspace in per-port round-robin order

On Wed, Jul 4, 2018 at 7:23 AM, Matteo Croce wrote: > From: Stefano Brivio > > Open vSwitch sends to userspace all received packets that have > no associated flow (thus doing an "upcall"). Then the userspace > program creates a new flow and determines the actions to apply > based on its

Re: [PATCH v2 net-next] openvswitch: kernel datapath clone action

On Mon, Jul 2, 2018 at 8:18 AM, Yifeng Sun wrote: > Add 'clone' action to kernel datapath by using existing functions. > When actions within clone don't modify the current flow, the flow > key is not cloned before executing clone actions. > > This is a follow up patch for this incomplete work: >

Re: [PATCH net-next] openvswitch: kernel datapath clone action

On Thu, Jun 28, 2018 at 8:20 AM, Yifeng Sun wrote: > Add 'clone' action to kernel datapath by using existing functions. > When actions within clone don't modify the current flow, the flow > key is not cloned before executing clone actions. > > This is a follow up patch for this incomplete work: >

Re: [PATCH net-next v5 1/2] openvswitch: Add conntrack limit netlink definition

On Thu, May 24, 2018 at 5:56 PM, Yi-Hung Wei wrote: > Define netlink messages and attributes to support user kernel > communication that uses the conntrack limit feature. > > Signed-off-by: Yi-Hung Wei Acked-by: Pravin B Shelar

Re: [PATCH net-next v5 2/2] openvswitch: Support conntrack zone limit

On Thu, May 24, 2018 at 5:56 PM, Yi-Hung Wei wrote: > Currently, nf_conntrack_max is used to limit the maximum number of > conntrack entries in the conntrack table for every network namespace. > For the VMs and containers that reside in the same namespace, > they share the

Re: [PATCH net-next v4 2/2] openvswitch: Support conntrack zone limit

On Mon, May 21, 2018 at 5:16 PM, Yi-Hung Wei wrote: > Currently, nf_conntrack_max is used to limit the maximum number of > conntrack entries in the conntrack table for every network namespace. > For the VMs and containers that reside in the same namespace, > they share the

Re: [PATCH net-next v4 0/2] openvswitch: Support conntrack zone limit

On Wed, May 23, 2018 at 10:13 AM, David Miller wrote: > From: Yi-Hung Wei > Date: Mon, 21 May 2018 17:16:03 -0700 > >> v3->v4: >> - Addresses comments from Parvin that include simplify netlink API, >> and remove unncessary RCU lockings. >> -

Re: [PATCH net-next v3 1/2] openvswitch: Add conntrack limit netlink definition

On Mon, Apr 30, 2018 at 2:28 PM, Yi-Hung Wei wrote: > Define netlink messages and attributes to support user kernel > communication that uses the conntrack limit feature. > > Signed-off-by: Yi-Hung Wei > --- > include/uapi/linux/openvswitch.h | 62 >

Re: [PATCH net-next v3 2/2] openvswitch: Support conntrack zone limit

On Mon, Apr 30, 2018 at 2:28 PM, Yi-Hung Wei wrote: > Currently, nf_conntrack_max is used to limit the maximum number of > conntrack entries in the conntrack table for every network namespace. > For the VMs and containers that reside in the same namespace, > they share the

Re: [PATCH net-next v2 2/2] openvswitch: Support conntrack zone limit

On Wed, Apr 25, 2018 at 2:51 PM, Yi-Hung Wei wrote: >>> +#ifIS_ENABLED(CONFIG_NETFILTER_CONNCOUNT) >>> +#define OVS_CT_LIMIT_UNLIMITED 0 >>> +#define OVS_CT_LIMIT_DEFAULT OVS_CT_LIMIT_UNLIMITED >>> +#define CT_LIMIT_HASH_BUCKETS 512 >>> + >> Can you use static key when

Re: [PATCH net-next v2 0/2] openvswitch: Support conntrack zone limit

On Mon, Apr 23, 2018 at 2:19 PM, Yi-Hung Wei <yihung@gmail.com> wrote: > On Mon, Apr 23, 2018 at 1:10 PM, Pravin Shelar <pshe...@ovn.org> wrote: >> On Mon, Apr 23, 2018 at 6:39 AM, David Miller <da...@davemloft.net> wrote: >>> From: Yi-Hung Wei <yihung...

Re: [PATCH net-next v2 2/2] openvswitch: Support conntrack zone limit

On Tue, Apr 17, 2018 at 5:30 PM, Yi-Hung Wei wrote: > Currently, nf_conntrack_max is used to limit the maximum number of > conntrack entries in the conntrack table for every network namespace. > For the VMs and containers that reside in the same namespace, > they share the

Re: [PATCH net-next v2 0/2] openvswitch: Support conntrack zone limit

On Mon, Apr 23, 2018 at 6:39 AM, David Miller wrote: > From: Yi-Hung Wei > Date: Tue, 17 Apr 2018 17:30:27 -0700 > >> Currently, nf_conntrack_max is used to limit the maximum number of >> conntrack entries in the conntrack table for every network

Re: [PATCH net] net: fix possible out-of-bound read in skb_network_protocol()

On Mon, Mar 26, 2018 at 8:08 AM, Eric Dumazet wrote: > skb mac header is not necessarily set at the time skb_network_protocol() > is called. Use skb->data instead. > > BUG: KASAN: slab-out-of-bounds in skb_network_protocol+0x46b/0x4b0 > net/core/dev.c:2739 > Read of size 2

Re: [PATCH net v2] openvswitch: meter: fix the incorrect calculation of max delta_t

On Thu, Mar 8, 2018 at 6:08 PM, zhangliping wrote: > From: zhangliping > > Max delat_t should be the full_bucket/rate instead of the full_bucket. > Also report EINVAL if the rate is zero. > > Fixes: 96fbc13d7e77 ("openvswitch: Add meter

Re: [PATCHv2 net-next] openvswitch: fix vport packet length check.

On Wed, Mar 7, 2018 at 3:38 PM, William Tu wrote: > When sending a packet to a tunnel device, the dev's hard_header_len > could be larger than the skb->len in function packet_length(). > In the case of ip6gretap/erspan, hard_header_len = LL_MAX_HEADER + t_hlen, > which is

Re: [PATCH net-next] openvswitch: fix vport packet length check.

On Tue, Mar 6, 2018 at 5:56 PM, William Tu wrote: > When sending a packet to a tunnel device, the dev's hard_header_len > could be larger than the skb->len in function packet_length(). > In the case of ip6gretap/erspan, hard_header_len = LL_MAX_HEADER + t_hlen, > which is

Re: [PATCH v4] openvswitch: Remove padding from packet before L3+ conntrack processing

On Wed, Jan 31, 2018 at 6:48 PM, Ed Swierk wrote: > IPv4 and IPv6 packets may arrive with lower-layer padding that is not > included in the L3 length. For example, a short IPv4 packet may have > up to 6 bytes of padding following the IP payload when received on an >

Re: [PATCHv6 net-next 3/3] openvswitch: add erspan version I and II support

On Thu, Jan 25, 2018 at 1:20 PM, William Tu wrote: > The patch adds support for openvswitch to configure erspan > v1 and v2. The OVS_TUNNEL_KEY_ATTR_ERSPAN_OPTS attr is added > to uapi as a binary blob to support all ERSPAN v1 and v2's > fields. Note that Previous commit

Re: [PATCHv6 net-next 2/3] net: erspan: create erspan metadata uapi header

On Thu, Jan 25, 2018 at 1:20 PM, William Tu wrote: > The patch adds a new uapi header file, erspan.h, and moves > the 'struct erspan_metadata' from internal erspan.h to it. > > Signed-off-by: William Tu Acked-by: Pravin B Shelar Thanks.

Re: [PATCHv6 net-next 1/3] net: erspan: use bitfield instead of mask and offset

On Thu, Jan 25, 2018 at 1:20 PM, William Tu wrote: > Originally the erspan fields are defined as a group into a __be16 field, > and use mask and offset to access each field. This is more costly due to > calling ntohs/htons. The patch changes it to use bitfields. > >

Re: [PATCHv5 net-next 2/2] openvswitch: add erspan version I and II support

On Thu, Jan 25, 2018 at 10:34 AM, William Tu <u9012...@gmail.com> wrote: > Thanks for the review. > > On Thu, Jan 25, 2018 at 9:32 AM, Pravin Shelar <pshe...@ovn.org> wrote: >> On Wed, Jan 24, 2018 at 11:06 AM, William Tu <u9012...@gmail.com> wrote: >>&

Re: [PATCHv5 net-next 2/2] openvswitch: add erspan version I and II support

On Wed, Jan 24, 2018 at 11:06 AM, William Tu wrote: > The patch adds support for openvswitch to configure erspan > v1 and v2. The OVS_TUNNEL_KEY_ATTR_ERSPAN_OPTS attr is added > to uapi as a binary blob to support all ERSPAN v1 and v2's > fields. Note that Previous commit

Re: [PATCH v3 1/2] skbuff: Add skb_network_trim

On Mon, Jan 22, 2018 at 6:42 PM, Ed Swierk wrote: > IPv4 and IPv6 packets may arrive with lower-layer padding that is not > included in the L3 length. For example, a short IPv4 packet may have > up to 6 bytes of padding following the IP payload when received on an >

Re: [PATCH 0/3] Check gso_size of packets when forwarding

On Mon, Jan 22, 2018 at 12:14 PM, David Miller <da...@davemloft.net> wrote: > From: Pravin Shelar <pshe...@ovn.org> > Date: Fri, 19 Jan 2018 13:54:15 -0800 > >> I agree it is not perfect. But the other proposed patch does not fix >> the connectivity issue. I

Re: [PATCH v3 2/2] openvswitch: Remove padding from packet before L3+ conntrack processing

On Mon, Jan 22, 2018 at 6:42 PM, Ed Swierk wrote: > In the OVS conntrack receive path, ovs_ct_execute() pulls the skb to > the L3 header but does not trim it to the L3 length before calling > nf_conntrack_in(NF_INET_PRE_ROUTING). When nf_conntrack_proto_tcp >

Re: [PATCH v3 1/2] skbuff: Add skb_network_trim

On Mon, Jan 22, 2018 at 6:42 PM, Ed Swierk wrote: > IPv4 and IPv6 packets may arrive with lower-layer padding that is not > included in the L3 length. For example, a short IPv4 packet may have > up to 6 bytes of padding following the IP payload when received on an >

Re: [PATCHv4 net-next 2/2] openvswitch: add erspan version I and II support

On Thu, Jan 18, 2018 at 2:04 PM, William Tu wrote: > The patch adds support for openvswitch to configure erspan > v1 and v2. The OVS_TUNNEL_KEY_ATTR_ERSPAN_OPTS attr is added > to uapi as a nested attribute to support all ERSPAN v1 and v2's > fields. Note taht Previous

Re: [PATCH 0/3] Check gso_size of packets when forwarding

On Fri, Jan 19, 2018 at 3:58 AM, Daniel Axtens <d...@axtens.net> wrote: > Pravin Shelar <pshe...@ovn.org> writes: > >> On Thu, Jan 18, 2018 at 5:28 PM, Daniel Axtens <d...@axtens.net> wrote: >>> Pravin Shelar <pshe...@ovn.org> writes: >>>

Re: [PATCH 0/3] Check gso_size of packets when forwarding

On Thu, Jan 18, 2018 at 5:28 PM, Daniel Axtens <d...@axtens.net> wrote: > Pravin Shelar <pshe...@ovn.org> writes: > >> On Thu, Jan 18, 2018 at 5:08 AM, Daniel Axtens <d...@axtens.net> wrote: >>> Pravin Shelar <pshe...@ovn.org> writes: >>>

Re: [PATCH 0/3] Check gso_size of packets when forwarding

On Thu, Jan 18, 2018 at 5:08 AM, Daniel Axtens <d...@axtens.net> wrote: > Pravin Shelar <pshe...@ovn.org> writes: > >> On Mon, Jan 15, 2018 at 6:09 PM, Daniel Axtens <d...@axtens.net> wrote: >>> When regular packets are forwarded, we validate their size

Re: [PATCH 0/3] Check gso_size of packets when forwarding

On Mon, Jan 15, 2018 at 6:09 PM, Daniel Axtens wrote: > When regular packets are forwarded, we validate their size against the > MTU of the destination device. However, when GSO packets are > forwarded, we do not validate their size against the MTU. We > implicitly assume that

Re: [PATCH net] Revert "openvswitch: Add erspan tunnel support."

urrent attr is a be32 supporting only one field. Thus, this > patch reverts it and later patch will redo it using nested attr. > > Signed-off-by: William Tu <u9012...@gmail.com> > Cc: Jiri Benc <jb...@redhat.com> > Cc: Pravin Shelar <pshe...@ovn.org> Acked-by: Pravin B Shelar <pshe...@ovn.org>

Re: [PATCHv2 net-next 2/2] openvswitch: add erspan version II support

On Fri, Jan 12, 2018 at 12:27 AM, Jiri Benc wrote: > On Thu, 11 Jan 2018 08:34:14 -0800, William Tu wrote: >> I'd also prefer reverting ceaa001a170e since it's more clean but I >> also hope to have this feature in 4.15. >> How long does reverting take? Am I only able to submit

Re: [PATCH v2] openvswitch: Trim off padding before L3+ netfilter processing

On Mon, Jan 8, 2018 at 7:02 PM, Ed Swierk <eswi...@skyportsystems.com> wrote: > On 1/6/18 10:57, Pravin Shelar wrote: >> On Fri, Jan 5, 2018 at 10:59 PM, Ed Swierk <eswi...@skyportsystems.com> >> wrote: >>> >>> >>> On Jan 5, 2018 22:17, "

Re: [PATCH net-next 2/2] openvswitch: add erspan version II support

On Tue, Jan 9, 2018 at 7:17 AM, William Tu <u9012...@gmail.com> wrote: > On Mon, Jan 8, 2018 at 4:03 PM, Pravin Shelar <pshe...@ovn.org> wrote: >> On Fri, Jan 5, 2018 at 2:29 PM, William Tu <u9012...@gmail.com> wrote: >>> The patch adds support for configur

Re: [PATCH v2] openvswitch: Trim off padding before L3+ netfilter processing

On Sat, Jan 6, 2018 at 10:57 AM, Pravin Shelar <pshe...@ovn.org> wrote: > On Fri, Jan 5, 2018 at 10:59 PM, Ed Swierk <eswi...@skyportsystems.com> wrote: >> >> >> On Jan 5, 2018 22:17, "Pravin Shelar" <pshe...@ovn.org> wrote: >

Re: [PATCH net-next 2/2] openvswitch: add erspan version II support

On Fri, Jan 5, 2018 at 2:29 PM, William Tu wrote: > The patch adds support for configuring the erspan version II > fields for openvswitch. > The patch looks good, But it could change userspace API for OVS_TUNNEL_KEY_ATTR_ERSPAN_OPTS, how are we going to handle compatibility?

Re: [PATCH v2] openvswitch: Trim off padding before L3+ netfilter processing

On Fri, Jan 5, 2018 at 10:59 PM, Ed Swierk <eswi...@skyportsystems.com> wrote: > > > On Jan 5, 2018 22:17, "Pravin Shelar" <pshe...@ovn.org> wrote: > > On Fri, Jan 5, 2018 at 3:20 PM, Ed Swierk <eswi...@skyportsystems.com> > wrote: >&

Re: [PATCH v2] openvswitch: Trim off padding before L3+ netfilter processing

On Fri, Jan 5, 2018 at 3:20 PM, Ed Swierk <eswi...@skyportsystems.com> wrote: > On Fri, Jan 5, 2018 at 10:14 AM, Ed Swierk <eswi...@skyportsystems.com> > wrote: >> On Thu, Jan 4, 2018 at 7:36 PM, Pravin Shelar <pshe...@ovn.org> wrote: >>> OVS already pull

Re: [PATCH v2] openvswitch: Trim off padding before L3+ netfilter processing

On Wed, Jan 3, 2018 at 7:49 PM, Ed Swierk <eswi...@skyportsystems.com> wrote: > On Fri, Dec 22, 2017 at 3:31 PM, Pravin Shelar <pshe...@ovn.org> wrote: >> On Thu, Dec 21, 2017 at 7:17 AM, Ed Swierk <eswi...@skyportsystems.com> >> wrote: >>> IPv4 an

Re: [PATCH] MAINTAINERS: Update my email address.

On Thu, Jan 4, 2018 at 10:38 AM, David Miller <da...@davemloft.net> wrote: > From: Pravin B Shelar <pshe...@ovn.org> > Date: Tue, 2 Jan 2018 20:14:42 -0800 > >> Signed-off-by: Pravin Shelar <pshe...@ovn.org> > > Applied, but please take Joe's feedback into

Re: [PATCH v2] openvswitch: Trim off padding before L3+ netfilter processing

On Fri, Dec 22, 2017 at 4:39 PM, Ed Swierk <eswi...@skyportsystems.com> wrote: > On Fri, Dec 22, 2017 at 3:31 PM, Pravin Shelar <pshe...@ovn.org> wrote: >> On Thu, Dec 21, 2017 at 7:17 AM, Ed Swierk <eswi...@skyportsystems.com> >> wrote: >>> IPv4 an

Re: [ovs-dev] Pravin Shelar

On Tue, Jan 2, 2018 at 11:36 AM, David Miller <da...@davemloft.net> wrote: > From: Pravin Shelar <pshe...@ovn.org> > Date: Thu, 28 Dec 2017 15:47:39 -0800 > >> Thanks Joe for the patch. But it is corrupted. I will send updated patch >> soon. > > I'm stil

Re: [ovs-dev] Pravin Shelar

On Wed, Dec 27, 2017 at 10:33 AM, Joe Perches <j...@perches.com> wrote: > On Wed, 2017-12-27 at 10:25 -0800, Ben Pfaff wrote: >> On Wed, Dec 27, 2017 at 04:22:55PM +0100, Julia Lawall wrote: >> > The email address pshe...@nicira.com listed for Pravin Shelar in >> >

Re: [PATCH v2] openvswitch: Trim off padding before L3+ netfilter processing

On Thu, Dec 21, 2017 at 7:17 AM, Ed Swierk wrote: > IPv4 and IPv6 packets may arrive with lower-layer padding that is not > included in the L3 length. For example, a short IPv4 packet may have > up to 6 bytes of padding following the IP payload when received on an >

Re: [PATCH] openvswitch: Trim off padding before L3 conntrack processing

On Thu, Dec 14, 2017 at 12:05 PM, Ed Swierk <eswi...@skyportsystems.com> wrote: > On Wed, Dec 13, 2017 at 4:58 PM, Pravin Shelar <pshe...@ovn.org> wrote: >> On Tue, Dec 12, 2017 at 8:17 AM, Ed Swierk <eswi...@skyportsystems.com> >> wrote: >>> A short IPv

Re: [PATCH] openvswitch: Trim off padding before L3 conntrack processing

On Tue, Dec 12, 2017 at 8:17 AM, Ed Swierk wrote: > A short IPv4 packet may have up to 6 bytes of padding following the IP > payload when received on an Ethernet device. > > In the normal IPv4 receive path, ip_rcv() trims the packet to > ip_hdr->tot_len before invoking

Re: [ovs-dev] [PATCH 7/8] net: ovs: remove unused hardirq.h

Yang Shi <yan...@alibaba-inc.com> > Cc: Pravin Shelar <pshe...@nicira.com> > Cc: "David S. Miller" <da...@davemloft.net> > Cc: d...@openvswitch.org Acked-by: Pravin B Shelar <pshe...@ovn.org>

Re: [PATCH net-next] openvswitch: do not propagate headroom updates to internal port

On Thu, Nov 30, 2017 at 6:35 AM, Paolo Abeni wrote: > After commit 3a927bc7cf9d ("ovs: propagate per dp max headroom to > all vports") the need_headroom for the internal vport is updated > accordingly to the max needed headroom in its datapath. > > That avoids the

Re: [PATCH] openvswitch: use ktime_get_ts64() instead of ktime_get_ts()

On Mon, Nov 27, 2017 at 5:11 PM, Arnd Bergmann wrote: > timespec is deprecated because of the y2038 overflow, so let's convert > this one to ktime_get_ts64(). The code is already safe even on 32-bit > architectures, since it uses monotonic times. On 64-bit architectures, > nothing

Re: [PATCH net] openvswitch: fix the incorrect flow action alloc size

On Sat, Nov 25, 2017 at 7:32 PM, zhangliping wrote: > From: zhangliping > > If we want to add a datapath flow, which has more than 500 vxlan outputs' > action, we will get the following error reports: > openvswitch: netlink: Flow action size 32832

Re: [ovs-dev] [PATCH net-next] openvswitch: Using kfree_rcu() to simplify the code

On Tue, Nov 14, 2017 at 11:57 AM, Wei Yongjun wrote: > The callback function of call_rcu() just calls a kfree(), so we > can use kfree_rcu() instead of call_rcu() + callback function. > > Signed-off-by: Wei Yongjun Acked-by: Pravin B Shelar

Re: [ovs-dev] [PATCH net-next] openvswitch: Make local function ovs_nsh_key_attr_size() static

On Tue, Nov 14, 2017 at 11:57 AM, Wei Yongjun wrote: > Fixes the following sparse warnings: > > net/openvswitch/flow_netlink.c:340:8: warning: > symbol 'ovs_nsh_key_attr_size' was not declared. Should it be static? > Acked-by: Pravin B Shelar >

Re: [ovs-dev] [PATCH net-next] openvswitch: Fix return value check in ovs_meter_cmd_features()

On Tue, Nov 14, 2017 at 11:50 AM, Wei Yongjun wrote: > In case of error, the function ovs_meter_cmd_reply_start() returns > ERR_PTR() not NULL. The NULL test in the return value check should > be replaced with IS_ERR(). > > Fixes: 96fbc13d7e77 ("openvswitch: Add meter

Re: [net-next v5 0/4] Openvswitch meter action

On Sat, Nov 11, 2017 at 1:39 AM, Andy Zhou wrote: > This patch series is the first attempt to add openvswitch > meter support. We have previously experimented with adding > metering support in nftables. However 1) It was not clear > how to expose a named nftables object cleanly,

Re: [ovs-dev] [PATCH] openvswitch: add null pointer check on upcall

On Thu, Nov 9, 2017 at 7:29 PM, Colin King wrote: > From: Colin Ian King > > upcall may be assigned a NULL pointer as genlmsg_put can potentially > return a NULL. Add a null check to avoid a null pointer dereference > on upcall. > > Detected

Re: [net-next v4 4/4] openvswitch: Add meter action support

On Thu, Nov 9, 2017 at 11:00 AM, Andy Zhou wrote: > Implements OVS kernel meter action support. > > Signed-off-by: Andy Zhou > --- I could not apply this patch on latest net-next.

Re: [net-next v4 3/4] openvswitch: Add meter infrastructure

On Thu, Nov 9, 2017 at 11:00 AM, Andy Zhou wrote: > OVS kernel datapath so far does not support Openflow meter action. > This is the first stab at adding kernel datapath meter support. > This implementation supports only drop band type. > > Signed-off-by: Andy Zhou

Re: [net-next v4 1/4] openvswitch: Add meter netlink definitions

On Thu, Nov 9, 2017 at 11:00 AM, Andy Zhou wrote: > Meter has its own netlink family. Define netlink messages and attributes > for communicating with the user space programs. > > Signed-off-by: Andy Zhou Acked-by: Pravin B Shelar

Re: [net-next v4 2/4] openvswitch: export get_dp() API.

On Thu, Nov 9, 2017 at 11:00 AM, Andy Zhou wrote: > Later patches will invoke get_dp() outside of datapath.c. Export it. > > Signed-off-by: Andy Zhou Acked-by: Pravin B Shelar

Re: [PATCH net-next v15] openvswitch: enable NSH support

On Tue, Nov 7, 2017 at 3:55 AM, Yang, Yi <yi.y.y...@intel.com> wrote: > On Tue, Nov 07, 2017 at 03:58:35AM -0800, Pravin Shelar wrote: >> On Tue, Nov 7, 2017 at 3:28 AM, Yang, Yi <yi.y.y...@intel.com> wrote: >> > On Tue, Nov 07, 2017 at 06:57:30PM +0800, Pravin She

Re: [PATCH net-next v15] openvswitch: enable NSH support

On Tue, Nov 7, 2017 at 3:28 AM, Yang, Yi <yi.y.y...@intel.com> wrote: > On Tue, Nov 07, 2017 at 06:57:30PM +0800, Pravin Shelar wrote: >> On Mon, Nov 6, 2017 at 4:22 AM, Jiri Benc <jb...@redhat.com> wrote: >> > On Sat, 4 Nov 2017 07:29:46 -0700, Pravin Shelar wrote

Re: [PATCH net-next v15] openvswitch: enable NSH support

On Mon, Nov 6, 2017 at 4:22 AM, Jiri Benc <jb...@redhat.com> wrote: > On Sat, 4 Nov 2017 07:29:46 -0700, Pravin Shelar wrote: >> > +int nsh_push(struct sk_buff *skb, const struct nshhdr *pushed_nh) >> > +{ >> > + struct nshhdr *nh; >> >

Re: [PATCH net-next v15] openvswitch: enable NSH support

On Sun, Nov 5, 2017 at 8:19 PM, Yang, Yi <yi.y.y...@intel.com> wrote: > On Sat, Nov 04, 2017 at 10:29:46PM +0800, Pravin Shelar wrote: >> On Tue, Oct 31, 2017 at 9:03 PM, Yi Yang <yi.y.y...@intel.com> wrote: >> > +int nsh_push(struct sk_buff *skb,

Re: [net-next v3 0/4] Openvswitch meter action

On Mon, Nov 6, 2017 at 12:30 AM, Andy Zhou wrote: > This patch series is the first attempt to add openvswitch > meter support. We have previously experimented with adding > metering support in nftables. However 1) It was not clear > how to expose a named nftables object cleanly,

Re: [PATCH net-next v15] openvswitch: enable NSH support

On Tue, Oct 31, 2017 at 9:03 PM, Yi Yang wrote: > v14->v15 > - Check size in nsh_hdr_from_nlattr > - Fixed four small issues pointed out By Jiri and Eric > > v13->v14 > - Rename skb_push_nsh to nsh_push per Dave's comment > - Rename skb_pop_nsh to nsh_pop per Dave's

Re: [PATCH net-next v15] openvswitch: enable NSH support

On Thu, Nov 2, 2017 at 6:40 PM, Yang, Yi <yi.y.y...@intel.com> wrote: > On Thu, Nov 02, 2017 at 05:06:47AM -0700, Pravin Shelar wrote: >> On Wed, Nov 1, 2017 at 7:50 PM, Yang, Yi <yi.y.y...@intel.com> wrote: >> > On Thu, Nov 02, 2017 at 08:52:40AM +0800, Pravin Shel

Re: [net-next v2 3/4] openvswitch: Add meter infrastructure

On Thu, Nov 2, 2017 at 7:43 PM, Andy Zhou <az...@ovn.org> wrote: > On Thu, Nov 2, 2017 at 5:07 AM, Pravin Shelar <pshe...@ovn.org> wrote: >> On Thu, Nov 2, 2017 at 3:07 AM, Andy Zhou <az...@ovn.org> wrote: >>> On Fri, Oct 20, 2017 at 8:32 PM, Pravin Shelar <p

Re: [net-next v2 3/4] openvswitch: Add meter infrastructure

On Thu, Nov 2, 2017 at 3:07 AM, Andy Zhou <az...@ovn.org> wrote: > On Fri, Oct 20, 2017 at 8:32 PM, Pravin Shelar <pshe...@ovn.org> wrote: >> On Thu, Oct 19, 2017 at 5:58 PM, Andy Zhou <az...@ovn.org> wrote: >>> >>> On Thu, Oct 19, 2017 a

Re: [PATCH net-next v15] openvswitch: enable NSH support

On Wed, Nov 1, 2017 at 7:50 PM, Yang, Yi <yi.y.y...@intel.com> wrote: > On Thu, Nov 02, 2017 at 08:52:40AM +0800, Pravin Shelar wrote: >> On Tue, Oct 31, 2017 at 9:03 PM, Yi Yang <yi.y.y...@intel.com> wrote: >> > >> > OVS master and 2.8 branch has merged NSH

Re: [PATCH net-next v15] openvswitch: enable NSH support

On Tue, Oct 31, 2017 at 9:03 PM, Yi Yang wrote: > v14->v15 > - Check size in nsh_hdr_from_nlattr > - Fixed four small issues pointed out By Jiri and Eric > > v13->v14 > - Rename skb_push_nsh to nsh_push per Dave's comment > - Rename skb_pop_nsh to nsh_pop per Dave's

Re: [net-next v2 3/4] openvswitch: Add meter infrastructure

On Thu, Oct 19, 2017 at 5:58 PM, Andy Zhou <az...@ovn.org> wrote: > > On Thu, Oct 19, 2017 at 02:47 Pravin Shelar <pshe...@ovn.org> wrote: >> >> On Tue, Oct 17, 2017 at 12:36 AM, Andy Zhou <az...@ovn.org> wrote: >> > OVS kernel datapath

Re: [net-next v2 3/4] openvswitch: Add meter infrastructure

On Tue, Oct 17, 2017 at 12:36 AM, Andy Zhou wrote: > OVS kernel datapath so far does not support Openflow meter action. > This is the first stab at adding kernel datapath meter support. > This implementation supports only drop band type. > > Signed-off-by: Andy Zhou

Re: [net-next RFC 3/4] openvswitch: Add meter infrastructure

On Mon, Oct 16, 2017 at 12:05 AM, Andy Zhou <az...@ovn.org> wrote: > On Fri, Oct 13, 2017 at 5:12 PM, Pravin Shelar <pshe...@ovn.org> wrote: >> On Thu, Oct 12, 2017 at 3:38 PM, Andy Zhou <az...@ovn.org> wrote: >>> OVS kernel datapath so far do

Re: [net-next RFC 4/4] openvswitch: Add meter action support

On Thu, Oct 12, 2017 at 3:38 PM, Andy Zhou wrote: > Implements OVS kernel meter action support. > > Signed-off-by: Andy Zhou > --- > include/uapi/linux/openvswitch.h | 1 + > net/openvswitch/actions.c| 12 > net/openvswitch/datapath.h |

Re: [net-next RFC 3/4] openvswitch: Add meter infrastructure

On Thu, Oct 12, 2017 at 3:38 PM, Andy Zhou wrote: > OVS kernel datapath so far does not support Openflow meter action. > This is the first stab at adding kernel datapath meter support. > This implementation supports only drop band type. > > Signed-off-by: Andy Zhou

Re: [net-next RFC 0/4] Openvswitch meter action

On Thu, Oct 12, 2017 at 3:38 PM, Andy Zhou wrote: > This patch series is the first attempt to add openvswitch > meter support. We have previously experimented with adding > metering support in nftables. However 1) It was not clear > how to expose a named nftables object cleanly,

Re: [PATCH net-next v2] openvswitch: add ct_clear action

On Tue, Oct 10, 2017 at 1:54 PM, Eric Garver wrote: > This adds a ct_clear action for clearing conntrack state. ct_clear is > currently implemented in OVS userspace, but is not backed by an action > in the kernel datapath. This is useful for flows that may modify a > packet tuple

Re: [PATCH net-next] openvswitch: add ct_clear action

On Fri, Oct 6, 2017 at 9:44 AM, Eric Garver wrote: > This adds a ct_clear action for clearing conntrack state. ct_clear is > currently implemented in OVS userspace, but is not backed by an action > in the kernel datapath. This is useful for flows that may modify a > packet tuple

Re: [PATCHv2 net-next] openvswitch: Add erspan tunnel support.

On Wed, Oct 4, 2017 at 5:03 PM, William Tu wrote: > Add erspan netlink interface for OVS. > > Signed-off-by: William Tu > Cc: Pravin B Shelar > --- > v1->v2: remove unnecessary compat code. Looks good to me.

Re: [PATCH net-next] openvswitch: Add erspan tunnel support.

On Wed, Oct 4, 2017 at 5:02 AM, William Tu wrote: > Add type II erspan vport implementation. Since erspan protocol is > on top of the GRE header, the implementation is extended from the > existing gre implementation. > > Signed-off-by: William Tu > Cc:

Re: [PATCH net-next v9] openvswitch: enable NSH support

On Tue, Sep 26, 2017 at 6:39 PM, Yang, Yi wrote: > On Tue, Sep 26, 2017 at 06:49:14PM +0800, Jiri Benc wrote: >> On Tue, 26 Sep 2017 12:55:39 +0800, Yang, Yi wrote: >> > After push_nsh, the packet won't be recirculated to flow pipeline, so >> > key->eth.type must be set

Re: [PATCH v2] geneve: Fix setting ttl value in collect metadata mode

On Wed, Sep 13, 2017 at 4:15 AM, 严海双 <yanhaishu...@cmss.chinamobile.com> wrote: > > >> On 2017年9月13日, at 上午7:43, Pravin Shelar <pshe...@ovn.org> wrote: >> >> On Tue, Sep 12, 2017 at 12:05 AM, Haishuang Yan >> <yanhaishu...@cmss.chinamobile.com> wrot

Re: [PATCH v2] geneve: Fix setting ttl value in collect metadata mode

On Tue, Sep 12, 2017 at 12:05 AM, Haishuang Yan wrote: > Similar to vxlan/ipip tunnel, if key->tos is zero in collect metadata > mode, tos should also fallback to ip{4,6}_dst_hoplimit. > > Signed-off-by: Haishuang Yan > > ---

Re: [PATCH v4 1/2] ip_tunnel: fix ip tunnel lookup in collect_md mode

On Tue, Sep 12, 2017 at 2:47 AM, Haishuang Yan wrote: > In collect_md mode, if the tun dev is down, it still can call > ip_tunnel_rcv to receive on packets, and the rx statistics increase > improperly. > > When the md tunnel is down, it's not neccessary to

Re: [PATCH v2] openvswitch: Fix an error handling path in 'ovs_nla_init_match_and_action()'

On Mon, Sep 11, 2017 at 12:56 PM, Christophe JAILLET wrote: > All other error handling paths in this function go through the 'error' > label. This one should do the same. > > Fixes: 9cc9a5cb176c ("datapath: Avoid using stack larger than 1024.") > Signed-off-by:

Re: [PATCH] geneve: Fix setting ttl value in collect metadata mode

On Sun, Sep 3, 2017 at 5:49 AM, Haishuang Yan wrote: > If key->tos is zero in collect metadata mode, tos should fallback to > ip{4,6}_dst_hoplimit, same as normal mode. > > Signed-off-by: Haishuang Yan > --- >

Re: [PATCH net V3] openvswitch: fix skb_panic due to the incorrect actions attrlen

On Tue, Aug 15, 2017 at 10:30 PM, Liping Zhang wrote: > From: Liping Zhang > > For sw_flow_actions, the actions_len only represents the kernel part's > size, and when we dump the actions to the userspace, we will do the > convertions, so it's true size may

  1   2   3   4   5   >