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
()
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:
> >
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
> > >
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
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,
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
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
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
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
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
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] -
>
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.
>
>
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
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
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
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
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:
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
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
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.
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 +-
>
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
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
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
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
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
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!!
>
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
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
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
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
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
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
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
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
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:
> >
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
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
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
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.
>
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
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
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
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
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
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
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
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
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
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
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
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
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
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
>
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
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:
>
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
>
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
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
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:
>
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:
>
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
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:
>
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
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
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:
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
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
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
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
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
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
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
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
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
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
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
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:
> >>&
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:
> >>
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
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
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
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
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
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
>
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
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
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
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
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.
>
>
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:
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
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
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:
>&
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
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:
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
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
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
>
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 - 100 of 192 matches
Mail list logo