Re: [ovs-dev] [PATCH v2] MAINTAINERS.rst: Move several people to emeritus status

On Fri, May 19, 2023 at 7:53 AM Russell Bryant wrote: > > The following document discusses emeritus committer status: > > https://docs.openvswitch.org/en/latest/internals/committer-emeritus-status/ > > There are several people who I would guess consider themselves > emeritus committers but have

Re: [ovs-dev] [PATCH net-next v8] net: openvswitch: IPv6: Add IPv6 extension header support

() On Mon, Dec 6, 2021 at 3:00 PM Cpp Code wrote: > > On Thu, Dec 2, 2021 at 9:28 PM Pravin Shelar wrote: > > > > On Thu, Dec 2, 2021 at 12:20 PM Cpp Code wrote: > > > > > > On Wed, Dec 1, 2021 at 11:34 PM Pravin Shelar > > > wrote: > >

Re: [ovs-dev] [PATCH net-next v8] net: openvswitch: IPv6: Add IPv6 extension header support

On Thu, Dec 2, 2021 at 12:20 PM Cpp Code wrote: > > On Wed, Dec 1, 2021 at 11:34 PM Pravin Shelar wrote: > > > > On Wed, Nov 24, 2021 at 11:33 AM Toms Atteka wrote: > > > > > > This change adds a new OpenFlow field OFPXMT_OFB_IPV6_EXTHDR and > > >

Re: [ovs-dev] [PATCH net-next v8] net: openvswitch: IPv6: Add IPv6 extension header support

On Wed, Nov 24, 2021 at 11:33 AM Toms Atteka wrote: > > This change adds a new OpenFlow field OFPXMT_OFB_IPV6_EXTHDR and > packets can be filtered using ipv6_ext flag. > > Signed-off-by: Toms Atteka > --- > include/uapi/linux/openvswitch.h | 6 ++ > net/openvswitch/flow.c | 140

Re: [ovs-dev] [PATCH 2/2] openvswitch: Fix condition check in output_userspace() by using nla_ok()

On Fri, Sep 17, 2021 at 1:25 AM Jiasheng Jiang wrote: > > Just using 'rem > 0' might be unsafe, so it's better > to use the nla_ok() instead. > Because we can see from the nla_next() that > '*remaining' might be smaller than 'totlen'. And nla_ok() > will avoid it happening. > For example,

Re: [ovs-dev] [PATCH net-next v2] openvswitch: Introduce per-cpu upcall dispatch

On Thu, Jul 15, 2021 at 5:28 AM Mark Gray wrote: > > The Open vSwitch kernel module uses the upcall mechanism to send > packets from kernel space to user space when it misses in the kernel > space flow table. The upcall sends packets via a Netlink socket. > Currently, a Netlink socket is created

Re: [ovs-dev] [PATCH net-next] openvswitch: Introduce per-cpu upcall dispatch

On Wed, Jun 30, 2021 at 2:53 AM Mark Gray wrote: > > The Open vSwitch kernel module uses the upcall mechanism to send > packets from kernel space to user space when it misses in the kernel > space flow table. The upcall sends packets via a Netlink socket. > Currently, a Netlink socket is created

Re: [ovs-dev] [RFC net-next] openvswitch: Introduce per-cpu upcall dispatch

On Fri, Apr 30, 2021 at 8:33 AM Mark Gray wrote: > > The Open vSwitch kernel module uses the upcall mechanism to send > packets from kernel space to user space when it misses in the kernel > space flow table. The upcall sends packets via a Netlink socket. > Currently, a Netlink socket is created

Re: [ovs-dev] [PATCH net] net: openvswitch: fix TTL decrement action netlink message format

On Thu, Nov 19, 2020 at 1:04 AM Eelco Chaudron wrote: > > Currently, the openvswitch module is not accepting the correctly formated > netlink message for the TTL decrement action. For both setting and getting > the dec_ttl action, the actions should be nested in the > OVS_DEC_TTL_ATTR_ACTION

Re: [ovs-dev] [PATCH v2] datapath: Add a new action dec_ttl

On Fri, Nov 13, 2020 at 4:06 AM Ilya Maximets wrote: > > On 11/13/20 11:04 AM, Eelco Chaudron wrote: > > Add support for the dec_ttl action. Instead of programming the datapath with > > a flow that matches the packet TTL and an IP set, use a single dec_ttl > > action. > > > > The old behavior is

Re: [ovs-dev] [PATCH net-next v3 3/3] net: openvswitch: remove unnused keep_flows

On Mon, Aug 24, 2020 at 10:08 PM wrote: > > From: Tonghao Zhang > > keep_flows was introduced by [1], which used as flag to delete flows or not. > When rehashing or expanding the table instance, we will not flush the flows. > Now don't use it anymore, remove it. > > [1] - >

Re: [ovs-dev] [PATCH net-next v3 2/3] net: openvswitch: refactor flow free function

On Mon, Aug 24, 2020 at 10:08 PM wrote: > > From: Tonghao Zhang > > Decrease table->count and ufid_count unconditionally, > because we only don't use count or ufid_count to count > when flushing the flows. To simplify the codes, we > remove the "count" argument of table_instance_flow_free. > >

Re: [ovs-dev] [PATCH net-next v2 1/3] net: openvswitch: improve coding style

On Mon, Aug 24, 2020 at 12:37 AM wrote: > > From: Tonghao Zhang > > Not change the logic, just improve coding style. > > Cc: Pravin B Shelar > Signed-off-by: Tonghao Zhang Acked-by: Pravin B Shelar ___ dev mailing list d...@openvswitch.org

Re: [ovs-dev] [PATCH net-next v3 0/3] net: openvswitch: improve codes

On Tue, Aug 25, 2020 at 9:37 AM David Miller wrote: > > From: xiangxia.m@gmail.com > Date: Tue, 25 Aug 2020 13:06:33 +0800 > > > From: Tonghao Zhang > > > > This series patches are not bug fix, just improve codes. > > Pravin, please review this patch series. > Sorry for delay. I will have a

Re: [ovs-dev] [PATCH net] openvswitch: take into account de-fragmentation in execute_check_pkt_len

On Mon, Jun 22, 2020 at 5:02 AM Lorenzo Bianconi wrote: > > > On Fri, Jun 19, 2020 at 4:48 AM Lorenzo Bianconi wrote: > > > > > > ovs connection tracking module performs de-fragmentation on incoming > > > fragmented traffic. Take info account if traffic has been de-fragmented > > > in

Re: [ovs-dev] [PATCH net] openvswitch: take into account de-fragmentation in execute_check_pkt_len

On Fri, Jun 19, 2020 at 4:48 AM Lorenzo Bianconi wrote: > > ovs connection tracking module performs de-fragmentation on incoming > fragmented traffic. Take info account if traffic has been de-fragmented > in execute_check_pkt_len action otherwise we will perform the wrong > nested action

Re: [ovs-dev] [PATCH 1/1] openvswitch: fix infoleak in conntrack

On Mon, Jun 15, 2020 at 7:13 PM Xidong Wang wrote: > > From: xidongwang > > The stack object “zone_limit” has 3 members. In function > ovs_ct_limit_get_default_limit(), the member "count" is > not initialized and sent out via “nla_put_nohdr”. > > Signed-off-by: xidongwang Looks good. Acked-by:

Re: [ovs-dev] 答复: 答复: [PATCH] netdev-linux: remove sum of vport stats and kernel netdev stats

On Wed, Apr 29, 2020 at 11:07 AM William Tu wrote: > > On Tue, Apr 28, 2020 at 03:29:10AM +, 姜立东 wrote: > > Hi William, > > > > > -/* Use kernel netdev's packet and byte counts since vport's > > > counters > > > - * do not reflect packet counts on the wire when GSO, TSO or

Re: [ovs-dev] [PATCH] Bareudp Tunnel Support

On Sun, Apr 19, 2020 at 8:11 PM Martin Varghese wrote: > > From: Martin Varghese > > UDP tunnel encapsulation module for tunnelling different protocols like > MPLS, IP, NSH etc > > The Bareudp tunnel module provides a generic UDP L3 encapsulation > tunnelling module for tunnelling different

Re: [ovs-dev] [PATCH net-next v3 4/5] net: openvswitch: make EINVAL return value more obvious

On Wed, Apr 22, 2020 at 10:10 AM wrote: > > From: Tonghao Zhang > > Cc: Pravin B Shelar > Cc: Andy Zhou > Signed-off-by: Tonghao Zhang > --- > net/openvswitch/meter.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > Acked-by: Pravin B Shelar Thanks.

Re: [ovs-dev] [PATCH net-next v3 5/5] net: openvswitch: use u64 for meter bucket

On Wed, Apr 22, 2020 at 10:10 AM wrote: > > From: Tonghao Zhang > > When setting the meter rate to 4+Gbps, there is an > overflow, the meters don't work as expected. > > Cc: Pravin B Shelar > Cc: Andy Zhou > Signed-off-by: Tonghao Zhang > --- > net/openvswitch/meter.c | 2 +- >

Re: [ovs-dev] [PATCH net-next v3 2/5] net: openvswitch: set max limitation to meters

On Wed, Apr 22, 2020 at 10:10 AM wrote: > > From: Tonghao Zhang > > Don't allow user to create meter unlimitedly, which may cause > to consume a large amount of kernel memory. The max number > supported is decided by physical memory and 20K meters as default. > > Cc: Pravin B Shelar > Cc: Andy

Re: [ovs-dev] [PATCH net-next v3 1/5] net: openvswitch: expand the meters supported number

On Wed, Apr 22, 2020 at 10:10 AM wrote: > > From: Tonghao Zhang > > In kernel datapath of Open vSwitch, there are only 1024 > buckets of meter in one datapath. If installing more than > 1024 (e.g. 8192) meters, it may lead to the performance drop. > But in some case, for example, Open vSwitch

Re: [ovs-dev] [PATCH net-next v3 3/5] net: openvswitch: remove the unnecessary check

On Wed, Apr 22, 2020 at 10:10 AM wrote: > > From: Tonghao Zhang > > Before invoking the ovs_meter_cmd_reply_stats, "meter" > was checked, so don't check it agin in that function. > > Cc: Pravin B Shelar > Cc: Andy Zhou > Signed-off-by: Tonghao Zhang > --- > net/openvswitch/meter.c | 9

Re: [ovs-dev] [PATCH net-next v2 2/5] net: openvswitch: set max limitation to meters

On Sun, Apr 19, 2020 at 5:28 PM Tonghao Zhang wrote: > > On Mon, Apr 20, 2020 at 1:31 AM Pravin Shelar wrote: > > > > On Sat, Apr 18, 2020 at 10:25 AM wrote: > > > > > > From: Tonghao Zhang > > > > > > Don't allow user to create meter

Re: [ovs-dev] [PATCH net-next v2 1/5] net: openvswitch: expand the meters supported number

On Sun, Apr 19, 2020 at 5:23 PM Tonghao Zhang wrote: > > On Mon, Apr 20, 2020 at 1:29 AM Pravin Shelar wrote: > > > > On Sat, Apr 18, 2020 at 10:25 AM wrote: > > > > > > From: Tonghao Zhang > > > > > > In kernel datapath of Open vSwitch

Re: [ovs-dev] [PATCH] net: openvswitch: ovs_ct_exit to be done under ovs_lock

On Sun, Apr 19, 2020 at 1:44 AM wrote: > > From: Tonghao Zhang > > syzbot wrote: > | = > | WARNING: suspicious RCU usage > | 5.7.0-rc1+ #45 Not tainted > | - > | net/openvswitch/conntrack.c:1898 RCU-list traversed in non-reader section!! >

Re: [ovs-dev] [PATCH net-next v2 2/5] net: openvswitch: set max limitation to meters

On Sat, Apr 18, 2020 at 10:25 AM wrote: > > From: Tonghao Zhang > > Don't allow user to create meter unlimitedly, > which may cause to consume a large amount of kernel memory. > The 200,000 meters may be fine in general case. > > Cc: Pravin B Shelar > Cc: Andy Zhou > Signed-off-by: Tonghao

Re: [ovs-dev] [PATCH net-next v2 1/5] net: openvswitch: expand the meters supported number

On Sat, Apr 18, 2020 at 10:25 AM wrote: > > From: Tonghao Zhang > > In kernel datapath of Open vSwitch, there are only 1024 > buckets of meter in one dp. If installing more than 1024 > (e.g. 8192) meters, it may lead to the performance drop. > But in some case, for example, Open vSwitch used as

Re: [ovs-dev] [PATCH net-next v1 1/3] net: openvswitch: expand the meters number supported

wrote: > > > > On Wed, Apr 08, 2020 at 11:59:25PM +0800, Tonghao Zhang wrote: > > > On Wed, Apr 8, 2020 at 11:09 PM William Tu wrote: > > > > > > > > On Wed, Apr 01, 2020 at 06:50:09PM +0800, Tonghao Zhang wrote: > > > > > On Tue, Mar 31, 2020 at 11:57

Re: [ovs-dev] [PATCH net-next v1 1/3] net: openvswitch: expand the meters number supported

Ok, thanks. On Wed, Apr 1, 2020 at 3:50 AM Tonghao Zhang wrote: > > On Tue, Mar 31, 2020 at 11:57 AM Pravin Shelar wrote: > > > > On Sun, Mar 29, 2020 at 5:35 PM Tonghao Zhang > > wrote: > > > > > > On Mon, Mar 30, 2020 at 12:46 AM Pravin Shelar w

Re: [ovs-dev] [PATCH net-next v1 1/3] net: openvswitch: expand the meters number supported

On Sun, Mar 29, 2020 at 5:35 PM Tonghao Zhang wrote: > > On Mon, Mar 30, 2020 at 12:46 AM Pravin Shelar wrote: > > > > On Sat, Mar 28, 2020 at 8:46 AM wrote: > > > > > > From: Tonghao Zhang > > > > > > In kernel datapath of Open vSwitch

Re: [ovs-dev] [PATCH net-next v1 1/3] net: openvswitch: expand the meters number supported

On Sat, Mar 28, 2020 at 8:46 AM wrote: > > From: Tonghao Zhang > > In kernel datapath of Open vSwitch, there are only 1024 > buckets of meter in one dp. If installing more than 1024 > (e.g. 8192) meters, it may lead to the performance drop. > But in some case, for example, Open vSwitch used as

Re: [ovs-dev] [PATCH 00/25] netdev datapath vxlan offload

On Sun, Mar 1, 2020 at 8:25 PM Sriharsha Basavapatna via dev wrote: > > On Tue, Feb 18, 2020 at 3:30 PM Eli Britstein wrote: > > > > > > On 2/10/2020 11:16 PM, Hemal Shah wrote: > > > Eli, > > > > > > There are some fundamental architecture issues (multi HW tables vs. > > > single HW table, use

Re: [ovs-dev] [PATCH net-next v5] openvswitch: add TTL decrement action

On Sat, Feb 15, 2020 at 5:21 AM Matteo Croce wrote: > > New action to decrement TTL instead of setting it to a fixed value. > This action will decrement the TTL and, in case of expired TTL, drop it > or execute an action passed via a nested attribute. > The default TTL expired action is to drop

Re: [ovs-dev] Question Regarding ovs_packet_cmd_execute in Kernel Datapath

t; the stats of the first packet. Therefore I wanted to know, if there is a > specific reason why OVS_PACKET_CMD_EXECUTE > has to always use temporary kernel flows. > > > >> > > >> > On Thu, Feb 06, 2020 at 11:36:19AM -0800, Pravin Shelar wrote: > >

Re: [ovs-dev] Question Regarding ovs_packet_cmd_execute in Kernel Datapath

On Thu, Feb 6, 2020 at 12:18 PM Ben Pfaff wrote: > > On Thu, Feb 06, 2020 at 11:36:19AM -0800, Pravin Shelar wrote: > > Another option would be to add new command that install and execute > > packet in same netlink msg. That would save us a netlink msg to handle > > a

Re: [ovs-dev] Question Regarding ovs_packet_cmd_execute in Kernel Datapath

On Wed, Feb 5, 2020 at 10:11 AM Dincer Beken wrote: > > Hello all, > > I am not entirely new to Open vSwitch and am implementing new actions to > realize the TS25.446 SYNC algorithm from 3GPP to create an BM-SC component > for LTE-Multicast (eMBMS). I am lacking the experience to judge over the

Re: [ovs-dev] [PATCH net-next v3] openvswitch: add TTL decrement action

On Wed, Jan 15, 2020 at 8:40 AM Matteo Croce wrote: > > New action to decrement TTL instead of setting it to a fixed value. > This action will decrement the TTL and, in case of expired TTL, drop it > or execute an action passed via a nested attribute. > The default TTL expired action is to drop

Re: [ovs-dev] [PATCH net-next v2] openvswitch: add TTL decrement action

On Thu, Dec 19, 2019 at 8:36 AM Matteo Croce wrote: > > On Wed, Dec 18, 2019 at 4:06 AM Pravin Shelar wrote: > > > > On Tue, Dec 17, 2019 at 7:51 AM Matteo Croce wrote: > > > > > > New action to decrement TTL instead of setting it to a fixed value. >

Re: [ovs-dev] [PATCH net-next v2] openvswitch: add TTL decrement action

On Tue, Dec 17, 2019 at 7:51 AM Matteo Croce wrote: > > New action to decrement TTL instead of setting it to a fixed value. > This action will decrement the TTL and, in case of expired TTL, drop it > or execute an action passed via a nested attribute. > The default TTL expired action is to drop

Re: [ovs-dev] [PATCH net 1/2] openvswitch: support asymmetric conntrack

Downloading from patchwork is working for me. Its strange other patches in my mailbox does not has this issue. Thanks. On Mon, Nov 25, 2019 at 7:39 AM Aaron Conole wrote: > > Aaron Conole writes: > > > Pravin Shelar writes: > > > >> On Fri, Nov 8, 2019

Re: [ovs-dev] [PATCH net-next v4] net: openvswitch: add hash info to upcall

On Wed, Nov 13, 2019 at 7:05 AM wrote: > > From: Tonghao Zhang > > When using the kernel datapath, the upcall don't > include skb hash info relatived. That will introduce > some problem, because the hash of skb is important > in kernel stack. For example, VXLAN module uses > it to select UDP src

Re: [ovs-dev] [PATCH net-next] openvswitch: add TTL decrement action

On Tue, Nov 12, 2019 at 2:25 AM Matteo Croce wrote: > > New action to decrement TTL instead of setting it to a fixed value. > This action will decrement the TTL and, in case of expired TTL, send the > packet to userspace via output_userspace() to take care of it. > > Supports both IPv4 and IPv6

Re: [ovs-dev] [PATCH net-next v3] net: openvswitch: add hash info to upcall

On Tue, Nov 12, 2019 at 7:09 AM wrote: > > From: Tonghao Zhang > > When using the kernel datapath, the upcall don't > include skb hash info relatived. That will introduce > some problem, because the hash of skb is important > in kernel stack. For example, VXLAN module uses > it to select UDP src

Re: [ovs-dev] [PATCH net-next] net: openvswitch: add hash info to upcall

On Sun, Nov 10, 2019 at 3:44 AM wrote: > > From: Tonghao Zhang > > When using the kernel datapath, the upcall don't > add skb hash info relatived. That will introduce > some problem, because the hash of skb is very > important (e.g. vxlan module uses it for udp src port, > tx queue selection on

Re: [ovs-dev] [PATCH net 1/2] openvswitch: support asymmetric conntrack

On Fri, Nov 8, 2019 at 1:07 PM Aaron Conole wrote: > > The openvswitch module shares a common conntrack and NAT infrastructure > exposed via netfilter. It's possible that a packet needs both SNAT and > DNAT manipulation, due to e.g. tuple collision. Netfilter can support > this because it runs

Re: [ovs-dev] [PATCH net-next v2] net: openvswitch: select vport upcall portid directly

On Wed, Nov 6, 2019 at 8:34 AM wrote: > > From: Tonghao Zhang > > The commit 69c51582ff786 ("dpif-netlink: don't allocate per > thread netlink sockets"), in Open vSwitch ovs-vswitchd, has > changed the number of allocated sockets to just one per port > by moving the socket array from a per

Re: [ovs-dev] [PATCH net-next v6 05/10] net: openvswitch: optimize flow-mask looking up

On Mon, Nov 4, 2019 at 6:00 AM William Tu wrote: > > On Sat, Nov 2, 2019 at 11:50 PM Pravin Shelar wrote: > > > > On Fri, Nov 1, 2019 at 7:24 AM wrote: > > > > > > From: Tonghao Zhang > > > > > > The full looking up on flow table trav

Re: [ovs-dev] [PATCH net-next v6 10/10] net: openvswitch: simplify the ovs_dp_cmd_new

On Fri, Nov 1, 2019 at 7:24 AM wrote: > > From: Tonghao Zhang > > use the specified functions to init resource. > > Signed-off-by: Tonghao Zhang > Tested-by: Greg Rose Acked-by: Pravin B Shelar ___ dev mailing list d...@openvswitch.org

Re: [ovs-dev] [PATCH net-next v6 09/10] net: openvswitch: don't unlock mutex when changing the user_features fails

On Fri, Nov 1, 2019 at 7:24 AM wrote: > > From: Tonghao Zhang > > Unlocking of a not locked mutex is not allowed. > Other kernel thread may be in critical section while > we unlock it because of setting user_feature fail. > > Fixes: 95a7233c4 ("net: openvswitch: Set OvS recirc_id from tc chain

Re: [ovs-dev] [PATCH net-next v6 08/10] net: openvswitch: fix possible memleak on destroy flow-table

On Fri, Nov 1, 2019 at 7:24 AM wrote: > > From: Tonghao Zhang > > When we destroy the flow tables which may contain the flow_mask, > so release the flow mask struct. > > Signed-off-by: Tonghao Zhang > Tested-by: Greg Rose > --- Acked-by: Pravin B Shelar

Re: [ovs-dev] [PATCH net-next v6 07/10] net: openvswitch: add likely in flow_lookup

On Fri, Nov 1, 2019 at 7:24 AM wrote: > > From: Tonghao Zhang > > The most case *index < ma->max, and flow-mask is not NULL. > We add un/likely for performance. > > Signed-off-by: Tonghao Zhang > Tested-by: Greg Rose > Acked-by: William Tu > --- Acked-by: Pravin B Shelar

Re: [ovs-dev] [PATCH net-next v6 05/10] net: openvswitch: optimize flow-mask looking up

On Fri, Nov 1, 2019 at 7:24 AM wrote: > > From: Tonghao Zhang > > The full looking up on flow table traverses all mask array. > If mask-array is too large, the number of invalid flow-mask > increase, performance will be drop. > > One bad case, for example: M means flow-mask is valid and NULL >

Re: [ovs-dev] [PATCH net-next v6 06/10] net: openvswitch: simplify the flow_hash

On Fri, Nov 1, 2019 at 7:24 AM wrote: > > From: Tonghao Zhang > > Simplify the code and remove the unnecessary BUILD_BUG_ON. > > Signed-off-by: Tonghao Zhang > Tested-by: Greg Rose > Acked-by: William Tu > --- Acked-by: Pravin B Shelar ___ dev

Re: [ovs-dev] [PATCH net-next v6 04/10] net: openvswitch: optimize flow mask cache hash collision

On Fri, Nov 1, 2019 at 7:24 AM wrote: > > From: Tonghao Zhang > > Port the codes to linux upstream and with little changes. > > Pravin B Shelar, says: > | In case hash collision on mask cache, OVS does extra flow > | lookup. Following patch avoid it. > > Link: >

Re: [ovs-dev] [PATCH net-next v6 03/10] net: openvswitch: shrink the mask array if necessary

On Fri, Nov 1, 2019 at 7:24 AM wrote: > > From: Tonghao Zhang > > When creating and inserting flow-mask, if there is no available > flow-mask, we realloc the mask array. When removing flow-mask, > if necessary, we shrink mask array. > > Signed-off-by: Tonghao Zhang > Tested-by: Greg Rose >

Re: [ovs-dev] [PATCH net-next v6 02/10] net: openvswitch: convert mask list in mask array

On Fri, Nov 1, 2019 at 7:24 AM wrote: > > From: Tonghao Zhang > > Port the codes to linux upstream and with little changes. > > Pravin B Shelar, says: > | mask caches index of mask in mask_list. On packet recv OVS > | need to traverse mask-list to get cached mask. Therefore array > | is better

Re: [ovs-dev] [PATCH net-next v6 01/10] net: openvswitch: add flow-mask cache for performance

On Fri, Nov 1, 2019 at 7:24 AM wrote: > > From: Tonghao Zhang > > The idea of this optimization comes from a patch which > is committed in 2014, openvswitch community. The author > is Pravin B Shelar. In order to get high performance, I > implement it again. Later patches will use it. > > Pravin

Re: [ovs-dev] [PATCH net-next v4 08/10] net: openvswitch: fix possible memleak on destroy flow-table

On Tue, Oct 29, 2019 at 4:31 AM Tonghao Zhang wrote: > > On Tue, Oct 29, 2019 at 3:38 PM Pravin Shelar wrote: > > > > On Sun, Oct 27, 2019 at 11:49 PM Tonghao Zhang > > wrote: > > > > > > On Thu, Oct 24, 2019 at 3:14 PM Pravin Shelar wrote: >

Re: [ovs-dev] [PATCH net-next v4 08/10] net: openvswitch: fix possible memleak on destroy flow-table

On Sun, Oct 27, 2019 at 11:49 PM Tonghao Zhang wrote: > > On Thu, Oct 24, 2019 at 3:14 PM Pravin Shelar wrote: > > > > On Tue, Oct 22, 2019 at 7:35 PM Tonghao Zhang > > wrote: > > > > > > On Tue, Oct 22, 2019 at 2:58 PM Pravin Shelar wrote: >

Re: [ovs-dev] [PATCH net-next v4 08/10] net: openvswitch: fix possible memleak on destroy flow-table

On Tue, Oct 22, 2019 at 7:35 PM Tonghao Zhang wrote: > > On Tue, Oct 22, 2019 at 2:58 PM Pravin Shelar wrote: > > ... > > > > > > Sure, I can review it, Can you send the patch inlined in mail? > > > > Thanks. > diff --git a/net/openvswitch/flow_t

Re: [ovs-dev] [PATCH net-next v4 08/10] net: openvswitch: fix possible memleak on destroy flow-table

On Sun, Oct 20, 2019 at 10:02 PM Tonghao Zhang wrote: > > On Sat, Oct 19, 2019 at 2:12 AM Pravin Shelar wrote: > > > > On Thu, Oct 17, 2019 at 8:16 PM Tonghao Zhang > > wrote: > > > > > > On Fri, Oct 18, 2019 at 6:38 AM Pravin Shelar wrote: >

Re: [ovs-dev] [PATCH net-next v4 08/10] net: openvswitch: fix possible memleak on destroy flow-table

On Thu, Oct 17, 2019 at 8:16 PM Tonghao Zhang wrote: > > On Fri, Oct 18, 2019 at 6:38 AM Pravin Shelar wrote: > > > > On Wed, Oct 16, 2019 at 5:50 AM wrote: > > > > > > From: Tonghao Zhang > > > > > > When we destroy the flow tables whic

Re: [ovs-dev] [PATCH net-next v4 08/10] net: openvswitch: fix possible memleak on destroy flow-table

On Wed, Oct 16, 2019 at 5:50 AM wrote: > > From: Tonghao Zhang > > When we destroy the flow tables which may contain the flow_mask, > so release the flow mask struct. > > Signed-off-by: Tonghao Zhang > Tested-by: Greg Rose > --- > net/openvswitch/flow_table.c | 14 +- > 1 file

Re: [ovs-dev] [PATCH] net: openvswitch: free vport unless register_netdevice() succeeds

On Thu, Aug 8, 2019 at 8:55 PM Hillf Danton wrote: > > > syzbot found the following crash on: > > HEAD commit:1e78030e Merge tag 'mmc-v5.3-rc1' of git://git.kernel.org/.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=148d3d1a60 > kernel config:

Re: [ovs-dev] memory leak in internal_dev_create

On Tue, Aug 6, 2019 at 5:00 AM Hillf Danton wrote: > > > On Tue, 06 Aug 2019 01:58:05 -0700 > > Hello, > > > > syzbot found the following crash on: > > ... > > BUG: memory leak > > unreferenced object 0x8881228ca500 (size 128): > >comm "syz-executor032", pid 7015, jiffies 4294944622 (age

Re: [ovs-dev] [PATCH net-next] net: openvswitch: do not update max_headroom if new headroom is equal to old headroom

On Fri, Jul 5, 2019 at 9:08 AM Taehee Yoo wrote: > > When a vport is deleted, the maximum headroom size would be changed. > If the vport which has the largest headroom is deleted, > the new max_headroom would be set. > But, if the new headroom size is equal to the old headroom size, > updating

Re: [ovs-dev] [PATCH net-next] net: openvswitch: do not update max_headroom if new headroom is equal to old headroom

I was bit busy for last couple of days. I will finish review by EOD today. Thanks, Pravin. On Mon, Jul 8, 2019 at 4:22 PM Gregory Rose wrote: > > > > On 7/8/2019 4:18 PM, Gregory Rose wrote: > > On 7/8/2019 4:08 PM, David Miller wrote: > >> From: Taehee Yoo > >> Date: Sat, 6 Jul 2019 01:08:09

Re: [ovs-dev] [PATCH net-next v5] openvswitch: Make metadata_dst tunnel work in IP_TUNNEL_INFO_BRIDGE mode

On Wed, Mar 27, 2019 at 9:43 PM wrote: > > From: wenxu > > There is currently no support for the multicast/broadcast aspects > of VXLAN in ovs. In the datapath flow the tun_dst must specific. > But in the IP_TUNNEL_INFO_BRIDGE mode the tun_dst can not be specific. > And the packet can forward

Re: [ovs-dev] [PATCH v2] openvswitch: fix flow actions reallocation

On Wed, Mar 27, 2019 at 11:36 PM Andrea Righi wrote: > > The flow action buffer can be resized if it's not big enough to contain > all the requested flow actions. However, this resize doesn't take into > account the new requested size, the buffer is only increased by a factor > of 2x. This might

Re: [ovs-dev] [PATCH net-next v4] openvswitch: Make metadata_dst tunnel work in IP_TUNNEL_INFO_BRIDGE mode

On Tue, Mar 26, 2019 at 8:16 PM wrote: > > From: wenxu > > There is currently no support for the multicast/broadcast aspects > of VXLAN in ovs. In the datapath flow the tun_dst must specific. > But in the IP_TUNNEL_INFO_BRIDGE mode the tun_dst can not be specific. > And the packet can forward

Re: [ovs-dev] [PATCH] openvswitch: fix flow actions reallocation

On Wed, Mar 27, 2019 at 3:11 PM Andrea Righi wrote: > > The flow action buffer can be resized if it's not big enough to contain > all the requested flow actions. However, this resize doesn't take into > account the new requested size, the buffer is only increased by a factor > of 2x. This might

Re: [ovs-dev] [PATCH v2 net-next] net: openvswitch: Add a new action check_pkt_len

On Mon, Mar 25, 2019 at 5:44 PM wrote: > > From: Numan Siddique > > This patch adds a new action - 'check_pkt_len' which checks the > packet length and executes a set of actions if the packet > length is greater than the specified length or executes > another set of actions if the packet length

Re: [ovs-dev] [PATCH net-next v2] openvswitch: add seqadj extension when NAT is used.

On Mon, Mar 25, 2019 at 11:58 AM Flavio Leitner wrote: > > When the conntrack is initialized, there is no helper attached > yet so the nat info initialization (nf_nat_setup_info) skips > adding the seqadj ext. > > A helper is attached later when the conntrack is not confirmed > but is going to be

Re: [ovs-dev] [PATCH net-next v3] openvswitch: Make metadata_dst tunnel work in IP_TUNNEL_INFO_BRIDGE mode

On Mon, Mar 25, 2019 at 8:46 PM wrote: > > From: wenxu > > There is currently no support for the multicast/broadcast aspects > of VXLAN in ovs. In the datapath flow the tun_dst must specific. > But in the IP_TUNNEL_INFO_BRIDGE mode the tun_dst can not be specific. > And the packet can forward

Re: [ovs-dev] [PATCH net-next v2] openvswitch: Make metadata_dst tunnel work in IP_TUNNEL_INFO_BRIDGE mode

On Sat, Mar 23, 2019 at 4:03 AM wrote: > > From: wenxu > > There is currently no support for the multicast/broadcast aspects > of VXLAN in ovs. In the datapath flow the tun_dst must specific. > But in the IP_TUNNEL_INFO_BRIDGE mode the tun_dst can not be specific. > And the packet can forward

Re: [ovs-dev] [PATCH net-next] openvswitch: Make metadata_dst tunnel work in IP_TUNNEL_INFO_BRIDGE mode

On Sun, Mar 24, 2019 at 6:24 PM wenxu wrote: > > On 2019/3/25 上午2:46, Pravin Shelar wrote: > > On Sun, Mar 24, 2019 at 12:03 AM wenxu wrote: > >> On 2019/3/24 上午5:39, Pravin Shelar wrote: > >>> On Sat, Mar 23, 2019 at 2:18 AM wenxu wrote: > >>&

Re: [ovs-dev] [PATCH net-next] openvswitch: Make metadata_dst tunnel work in IP_TUNNEL_INFO_BRIDGE mode

On Sun, Mar 24, 2019 at 12:03 AM wenxu wrote: > > On 2019/3/24 上午5:39, Pravin Shelar wrote: > > On Sat, Mar 23, 2019 at 2:18 AM wenxu wrote: > >> On 2019/3/23 下午3:50, Pravin Shelar wrote: > >> > >> On Thu, Mar 21, 2019 at 3:34 AM wrote: > >>

Re: [ovs-dev] [PATCH net-next] openvswitch: Make metadata_dst tunnel work in IP_TUNNEL_INFO_BRIDGE mode

On Sat, Mar 23, 2019 at 2:18 AM wenxu wrote: > > On 2019/3/23 下午3:50, Pravin Shelar wrote: > > On Thu, Mar 21, 2019 at 3:34 AM wrote: > > From: wenxu > > There is currently no support for the multicasti/broadcst aspects > of VXLAN in ovs. In the datapath flo

Re: [ovs-dev] [PATCH net-next] openvswitch: add seqadj extension when NAT is used.

On Thu, Mar 21, 2019 at 9:52 AM Flavio Leitner wrote: > > When the conntrack is initialized, there is no helper attached > yet so the nat info initialization (nf_nat_setup_info) skips > adding the seqadj ext. > > A helper is attached later when the conntrack is not confirmed > but is going to be

Re: [ovs-dev] [PATCH net-next] openvswitch: Make metadata_dst tunnel work in IP_TUNNEL_INFO_BRIDGE mode

On Thu, Mar 21, 2019 at 3:34 AM wrote: > > From: wenxu > > There is currently no support for the multicasti/broadcst aspects > of VXLAN in ovs. In the datapath flow the tun_dst must specific. > But in the IP_TUNNEL_INFO_BRIDGE mode the tun_dst can not be specific. > And the packet can forward

Re: [ovs-dev] [PATCH net-next V2 1/1] openvswitch: Declare ovs key structures using macros

On Sun, Feb 3, 2019 at 1:12 AM Eli Britstein wrote: > > Declare ovs key structures using macros as a pre-step towards to > enable retrieving fields information, as a work done in proposed > commit in the OVS tree https://patchwork.ozlabs.org/patch/1023406/ > ("odp-util: Do not rewrite fields with

Re: [ovs-dev] [PATCH net-next 1/1] openvswitch: Declare ovs key structures using macros

Can you send patch with this information in commit msg? On Thu, Jan 31, 2019 at 3:32 AM Eli Britstein wrote: > > ping > > for the using patch, i put below the v1 of it. here is v2: > > https://patchwork.ozlabs.org/patch/1023406/ > > > On 1/27/2019 8:37 AM, Eli Britstein wrote: > > > > On

Re: [ovs-dev] [PATCH net-next 1/1] openvswitch: Declare ovs key structures using macros

On Thu, Jan 24, 2019 at 1:47 AM Eli Britstein wrote: > > Declare ovs key structures using macros to enable retrieving fields > information, with no functional change. > I am not sure why is this done. Can you explain what are u trying to solve here? > Signed-off-by: Eli Britstein >

Re: [ovs-dev] [PATCH] openvswitch: Avoid OOB read when parsing flow nlattrs

On Mon, Jan 14, 2019 at 1:17 AM Ross Lagerwall wrote: > > For nested and variable attributes, the expected length of an attribute > is not known and marked by a negative number. This results in an OOB > read when the expected length is later used to check if the attribute is > all zeros. Fix

Re: [ovs-dev] [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: [ovs-dev] [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: [ovs-dev] [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: [ovs-dev] [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: [ovs-dev] [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: [ovs-dev] [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: [ovs-dev] [PATCH nf-next v2] openvswitch: use nf_ct_get_tuplepr, invert_tuplepr

On Mon, Jun 25, 2018 at 8:55 AM, Florian Westphal wrote: > These versions deal with the l3proto/l4proto details internally. > It removes only caller of nf_ct_get_tuple, so make it static. > > After this, l3proto->get_l4proto() can be removed in a followup patch. > > Signed-off-by: Florian

Re: [ovs-dev] [PATCH] datapath: stt: linearize in SKIP_ZERO_COPY case

does not expect an skb with a frag_list to be >> present. This patch removes the assumption, and allows these skb to >> be linearized as intended. We confirmed this corrects the panic we >> encountered. >> >> Reported-by: Johannes Erdfelt >> Reported-at: >&

Re: [ovs-dev] [PATCH] datapath: ensure UFO traffic is actually fragmented

On Fri, Jun 15, 2018 at 1:21 PM, Gregory Rose wrote: > On 6/15/2018 1:05 PM, Ben Pfaff wrote: >> >> On Tue, May 29, 2018 at 06:06:19PM +, Neal Shrader via dev wrote: >>> >>> While investigating a kernel panic, our team noticed that UDP traffic >>> recieved by an STT tunnel will always have a

Re: [ovs-dev] [PATCH] vxlan: Fix for the packet loop issue in vxlan

e it even with linux bridge and vxlan device. Proposed patch is specific solution. You can add another layer of bridge and the patch would not handle same issue in that configuration. Therefore I am bit hesitant to apply this patch. > > > On Wed, Jun 13, 2018 at 12:21 PM, Pravin Shelar wrote:

Re: [ovs-dev] [PATCH] vxlan: Fix for the packet loop issue in vxlan

kernel version? > The macro (XMIT_RECURSION_LIMIT) is defined as 10. This limit wont prevent > the crash since the recursion is 2 only for my configuration. right, The recursion limit is to avoid stack overflow. > > > > On Wed, Jun 13, 2018 at 4:11 AM, Pravin Shelar w

Re: [ovs-dev] [PATCH] vxlan: Fix for the packet loop issue in vxlan

orking stack recursion limit (XMIT_RECURSION_LIMIT) and then the packet would be dropped. I am not sure which spinlock recursion issue you are referring to. > > > > > On Tue, Jun 12, 2018 at 11:55 AM, Pravin Shelar wrote: >> >> >> >> On Tue, May 22, 2018 at 10

Re: [ovs-dev] [PATCH] vxlan: Fix for the packet loop issue in vxlan

On Tue, May 22, 2018 at 10:16 PM, Neelakantam Gaddam wrote: > This patch fixes the kernel soft lockup issue with vxlan configuration > where the tunneled packet is sent on the same bridge where vxlan port is > attched to. It detects the loop in vxlan xmit functionb and drops if loop > is >

Re: [ovs-dev] [PATCH] compat: Fix upstream 4.4.119 kernel

On Fri, Apr 20, 2018 at 11:13 AM, Greg Rose wrote: > The Linux 4.4.119 kernel (and perhaps others) from kernel.org > backports some dst_cache code that breaks the openvswitch kernel > due to a duplicated name "dst_cache_destroy". For most cases the > "USE_UPSTREAM_TUNNEL"

  1   2   >