[ovs-dev] command name of daemon process is null after recover from crash

HI, all I find the comm name of daemon process is null after recover from crash. For example, 1. `ps -ef |grep ovs-vswitchd` : get the ovs-vswitchd pid (not the monitor) 2. `cat /proc/$pid/comm` : see name "ovs-vswitchd" 3. `kill -11 $pid` : make process segfault and crash 4. `ps -ef |grep

Re: [ovs-dev] [PATCH v2 5/5] odp-util: Always report ODP_FIT_TOO_LITTLE for IGMP.

ave an > opinion? > > On Mon, Feb 05, 2018 at 07:57:20PM +0800, Huanle Han wrote: >> The patches make "ODP_FIT_TOO_LITTLE" logic more clear for me. >> But it seems not fix the problem I mentioned at beginnig: >> revalidate_ukey__() always return UKEY_D

Re: [ovs-dev] [PATCH v2 5/5] odp-util: Always report ODP_FIT_TOO_LITTLE for IGMP.

LE" flows whose action is already "slow_path(action, match)" ? On Thu, Jan 25, 2018 at 3:40 AM, Ben Pfaff <b...@ovn.org> wrote: > OVS datapaths don't understand or parse IGMP fields, but OVS userspace > does, so this commit updates odp_flow_key_to_flow() to report that properl

Re: [ovs-dev] [PATCH 3/3] mirror: do not mirror packet on recirculation

cation. Can you help me by providing a full set of > commands? > > On Tue, Jan 30, 2018 at 11:12:34PM +0800, Huanle Han wrote: >> Thanks for your review. >> >> Here is a test case: >> 1. add a trunk, balance-tcp bond to a bridge >> 2. add a access port tag=xx

Re: [ovs-dev] [PATCH v2 1/5] xlate: fix packets loopback caused by duplicate read of xcfgp.

That 'ctx->xcfg' can't be null in my previous patch. This patch looks good to me. On Thu, Jan 25, 2018 at 3:40 AM, Ben Pfaff <b...@ovn.org> wrote: > From: Huanle Han <hanxue...@gmail.com> > > Some functions, such as xlate_normal_mcast_send_mrouters, test xbundle >

Re: [ovs-dev] [PATCH 3/3] mirror: do not mirror packet on recirculation

Pfaff <b...@ovn.org> wrote: > On Wed, Jan 24, 2018 at 09:41:12AM -0800, Ben Pfaff wrote: >> From: Huanle Han <hanxue...@gmail.com> >> >> Signed-off-by: Huanle Han <hanxue...@gmail.com> >> --- >> ofproto/ofproto-dpif-xlate.c | 4 >> 1

Re: [ovs-dev] [PATCH] Ofproto: fix the bug wrong datapath flow with same in_port and output port was generated

I have done a similar fix few months ago. The commit tries to avoid an inconsistent result caused by using different xcfg pointers. https://github.com/openvswitch/ovs/pull/210/commits/ec75e8d9bb0e16690447b40b39d2fd0fb0f7aae2 I think a few more place fixes needed for this patch:

Re: [ovs-dev] two possible bugs about ipv6 multicast

Does anybody has some advice for me? On Mon, Sep 4, 2017 at 11:40 PM, Huanle Han <hanxue...@gmail.com> wrote: > Hi, All > > I'm just learning ipv6. When I go through ovs code about ipv6 normal > forwarding, I find 2 possible "bugs". Could you explain some for me

[ovs-dev] two possible bugs about ipv6 multicast

Hi, All I'm just learning ipv6. When I go through ovs code about ipv6 normal forwarding, I find 2 possible "bugs". Could you explain some for me? Thanks. 1. In fucntion "xlate_normal". when mcast snooping is on, ipv6 neighbor discover packet, whose dest mac is "33:33:**", is proccessed in

[ovs-dev] packet loopback because different xcfgp pointer is used in xlate_normal*

Hi, Ben I find a bug in ovs that mcast packet loops back because a different xcfgp pointer is used in xlate_normal*(). I find it on v2.5.0 and I haven't verify it on master yet. Here is the my investigation: In function xlate_normal_mcast_send_group, the inbundle pointer and outbundle pointer

Re: [ovs-dev] incorrect revalidated action for igmp

nle On Wednesday, July 12, 2017, Ben Pfaff <b...@ovn.org> wrote: > On Thu, Jun 22, 2017 at 01:04:48AM +0800, Huanle Han wrote: > > In "Normal" action, igmp report packet is expected to processed in slow > > path. > > However, the igmp_type(flow->tp_src) is

Re: [ovs-dev] Fail to netdev_open internal iface with error "File exists"

gt;>On Thu, Jun 22, 2017 at 04:04:44PM -0300, Flavio Leitner wrote: > > >>>On Thu, Jun 22, 2017 at 01:04:59AM +0800, Huanle Han wrote: > > >>>>Hi,all > > >>>> > > >>>>I get this problem with latest(dbd8112) branch-2.7 code

[ovs-dev] Fail to netdev_open internal iface with error "File exists"

Hi,all I get this problem with latest(dbd8112) branch-2.7 code on my Ubuntu. root@ubuntu:/var/log/# ovs-vsctl show adf2ea99-0c53-4180-914f-7dadaa71302b Bridge test Port test Interface test type: internal Bridge "manage" Port "manage"

[ovs-dev] incorrect revalidated action for igmp

In "Normal" action, igmp report packet is expected to processed in slow path. However, the igmp_type(flow->tp_src) is not supported to be masked in datapath. Then ovs-vswitchd revalidate the flow with igmp_type(flow->tp_src) == 0. It leads to a "multicast traffic, flooding" action and overwrites

[ovs-dev] Why not implement netdev datapath in a separated process

Hi, I'm thinking about this quesion, after experience the dpdk feature in ovs. Could you give me some answer? Currently, netdev datapath(or called dpdk) is implemented inside daemon process "ovs-vswitchd". It makes ovs-vswitchd not that stable as before: 1. some ovsbd config for dpdk requires

Re: [ovs-dev] question about mirror code

2016-01-25 1:00 GMT+08:00 Ben Pfaff <b...@ovn.org>: > On Sun, Jan 24, 2016 at 11:59:57PM +0800, Huanle Han wrote: > > I think a more line "mirrors &= ~ctx->mirrors;" is needed at the end of > the > > "while" loop. > > Otherw

Re: [ovs-dev] question about mirror code

Hi, Ben, I think a more line "mirrors &= ~ctx->mirrors;" is needed at the end of the "while" loop. Otherwise, duplicated mirror action may be applied in recursive mirror_packet called by output_normal. Here are the test cases: Test case for the bug I mentioned in previous mail: 1. setup port:

[ovs-dev] why drop multicast packets on inactive slaves ?

hi, guys, I can't quit understand the code below in function "bond_check_admissibility". Could you do some explanation for me? Why drop the multicast packet on inactive slaves? Will upstream switch output multicast packet to each interface in aggregation? If not, will ovs lose the packet?