Re: [ovs-discuss] OVN - MTU path discovery

2018-08-02 Thread Ben Pfaff
On Thu, Aug 02, 2018 at 01:19:57PM -0700, Ben Pfaff wrote:
> On Wed, Aug 01, 2018 at 10:46:07AM -0400, Miguel Angel Ajo Pelayo wrote:
> > Hi Ben, ICMP is used as a signal from the router to tell the sender
> > “next hop has a lower mtu, please send smaller packets”, we would
> > need at least something in OVS to slow-path the “bigger than X” packets,
> > at that point ova-controller could take care of constructing the ICMP packet
> > and sending it to the source.
> 
> Yes.
> 
> > But I guess, that we still need the kernel changes to match on
> > those “big packets”.
> 
> Maybe.  If we only need to worry about ICMP, though, we can set up OVN
> so that it always slow-paths ICMP.

Oh, I think maybe I was just being slow.  The ICMP is generated, not
processed.  Never mind.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss


Re: [ovs-discuss] OVN - MTU path discovery

2018-08-02 Thread Ben Pfaff
On Wed, Aug 01, 2018 at 10:46:07AM -0400, Miguel Angel Ajo Pelayo wrote:
> Hi Ben, ICMP is used as a signal from the router to tell the sender
> “next hop has a lower mtu, please send smaller packets”, we would
> need at least something in OVS to slow-path the “bigger than X” packets,
> at that point ova-controller could take care of constructing the ICMP packet
> and sending it to the source.

Yes.

> But I guess, that we still need the kernel changes to match on
> those “big packets”.

Maybe.  If we only need to worry about ICMP, though, we can set up OVN
so that it always slow-paths ICMP.

> On 27 July 2018 at 23:35:58, Ben Pfaff (b...@ovn.org) wrote:
> 
> On Thu, Jul 12, 2018 at 04:03:33PM +0200, Miguel Angel Ajo Pelayo wrote:
> > Is there any way to match packet_size > X on a flow?
> >
> > How could we implement this?
> 
> OVS doesn't currently have a way to do that. Adding such a feature
> would require kernel changes.
> 
> You mentioned ICMP at one point. It would be pretty easy to implement
> such a feature specifically for ICMP to logical router IP addresses in
> OVN, because we could just slow-path such traffic to ovn-controller
> (maybe we already do?) and check the packet size there. I don't know
> whether there's value in that.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss


Re: [ovs-discuss] ofproto-dpif-upcall: reg. udpif_revalidator thread

2018-08-02 Thread Vishal Deep Ajmera
> >
> > Vishal, will you send a patch to do that?
> >
> 
> Thanks Ben and Ethan for reviewing. I will send a patch to fix this on 
> dev-list.
> 
Hi Ben, Ethan,

I have sent a patch fixing this issue on mailing list for review.

Warm Regards,
Vishal
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss


Re: [ovs-discuss] Bug in configuring of Ovs

2018-08-02 Thread Vikas Kumar
Vikas Kumar 2:37 PM (56 minutes ago)
hi Team, i am using ubuntu 16.0. i am trying to configure the ovs source
code...
Darrell Ball 
2:53 PM (40 minutes ago)
to me, bugs

Means your kernel has been upgraded to 4.15 in your Xenial environment
(check uname –r)



Latest OVS release supports up to 4.14



http://docs.openvswitch.org/en/latest/faq/releases/

Second question.


Thank you very much for the help.

Thanks
vikash

On Thu, Aug 2, 2018 at 2:53 PM, Darrell Ball  wrote:

> Means your kernel has been upgraded to 4.15 in your Xenial environment
> (check uname –r)
>
>
>
> Latest OVS release supports up to 4.14
>
>
>
> http://docs.openvswitch.org/en/latest/faq/releases/
>
> Second question.
>
>
>
>
>
> *From: * on behalf of Vikas Kumar <
> vikassanm...@gmail.com>
> *Date: *Thursday, August 2, 2018 at 2:08 AM
> *To: *"b...@openvswitch.org" 
> *Subject: *[ovs-discuss] Bug in configuring of Ovs
>
>
>
> hi Team,
>
> i am using ubuntu 16.0. i am trying to configure the ovs source code, but
> i am getting the below error message. please help me on this
>
>
>
> configure: error: Linux kernel in /lib/modules/4.15.0-29-generic/build is
> version 4.15.18, but version newer than 4.14.x is not supported (please
> refer to the FAQ for advice)
>
>
>
> Regards
>
> vikash
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss


[ovs-discuss] 答复: a question about ovs crash relationship with learn action

2018-08-02 Thread wangyunjian
This patch has problem.
But when the cache has XC_LEARN entry,the cache can't be executed multiple times
in xlate_push_stats. The ofm's match->flow in XC_LEARN entry may use-after-free.

>-邮件原件-
>发件人: Ben Pfaff [mailto:b...@ovn.org]
>发送时间: 2018年7月11日 5:00
>收件人: wangyunjian 
>抄送: d...@openvswitch.org; ovs-discuss@openvswitch.org; Lilijun (Jerry, Cloud
>Networking) 
>主题: Re: [ovs-discuss] a question about ovs crash relationship with learn action
>
>Can you explain further?  Throwing away the cache entries makes the cache
>less useful.
>
>Are you really using v2.7.0?  None of the line numbers match up, either in the
>backtrace or in the patch.
>
>On Tue, Jun 26, 2018 at 10:38:50AM +, wangyunjian wrote:
>> I think the function xlate_cache_clear() needs be called after
>> xlate_push_stats() to avoid xcache->entries use-after-free.
>>
>> diff --git a/ofproto/ofproto-dpif-upcall.c
>> b/ofproto/ofproto-dpif-upcall.c index 85f5792..71b846c 100644
>> --- a/ofproto/ofproto-dpif-upcall.c
>> +++ b/ofproto/ofproto-dpif-upcall.c
>> @@ -2252,6 +2252,7 @@ revalidate_ukey(struct udpif *udpif, struct
>udpif_key *ukey,
>>  /* Stats for deleted flows will be attributed upon flow deletion. Skip. 
>> */
>>  if (result != UKEY_DELETE) {
>>  xlate_push_stats(ukey->xcache, );
>> +xlate_cache_clear(ukey->xcache);
>>  ukey->stats = *stats;
>>  ukey->reval_seq = reval_seq;
>>  }
>>
>> > From: wangyunjian
>> > Sent: Monday, June 25, 2018 2:19 PM
>> > To: ovs-discuss@openvswitch.org
>> > Cc: 'b...@ovn.org' ; Lilijun (Jerry, Cloud Networking)
>> > 
>> > Subject: [ovs-discuss] a question about ovs crash relationship with
>> > learn action
>> >
>> > I'm running OVS 2.7.0 on a Linux 3.10.0 kernel. I found a ovs crash.
>> > I doubt it's caused by use-after-free set match->flow = NULL in
>> > minimatch_destroy function with following stack:
>> >
>> > (gdb) bt
>> > #0  0x7ff273b71197 in raise () from /usr/lib64/libc.so.6
>> > #1  0x7ff273b72888 in abort () from /usr/lib64/libc.so.6
>> > #2  0x00787289 in PAT_abort ()
>> > #3  0x007843cd in patchIllInsHandler ()
>> > #4  
>> > #5  0x004cbfae in miniflow_n_values (flow=0x0) at
>> > lib/flow.h:540
>> > #6  0x004cc95f in minimask_hash (mask=0x0, basis=0) at
>> > lib/classifier-private.h:321
>> > #7  0x004cf613 in find_subtable (cls=0x38ad6e8, mask=0x0) at
>> > lib/classifier.c:1406
>> > #8  0x004cefa7 in classifier_find_rule_exactly
>> > (cls=0x38ad6e8, target=0x7ff118025500, version=18446744073709551615)
>> > at lib/classifier.c:1178
>> > #9  0x0047bcaf in collect_rules_strict (ofproto=0x389bc30,
>> > criteria=0x7ff1180254f8, rules=0x7ff118025588) at
>> > ofproto/ofproto.c:4253
>> > #10 0x0047eba3 in modify_flow_start_strict
>> > (ofproto=0x389bc30, ofm=0x7ff1180254f0) at ofproto/ofproto.c:5492
>> > #11 0x00482c9f in ofproto_flow_mod_start (ofproto=0x389bc30,
>> > ofm=0x7ff1180254f0) at ofproto/ofproto.c:7506
>> > #12 0x0047dc01 in ofproto_flow_mod_learn_start
>> > (ofm=0x7ff1180254f0) at ofproto/ofproto.c:5088
>> > #13 0x0047dd4b in ofproto_flow_mod_learn
>> > (ofm=0x7ff1180254f0, keep_ref=true) at ofproto/ofproto.c:5140
>> > #14 0x004b55d4 in xlate_push_stats_entry
>> > (entry=0x7ff118015148, stats=0x7ff11d6675f0) at
>> > ofproto/ofproto-dpif-xlate-cache.c:130
>> > #15 0x004b57b6 in xlate_push_stats (xcache=0x7ff1180254a0,
>> > stats=0x7ff11d6675f0) at ofproto/ofproto-dpif-xlate-cache.c:183
>> > #16 0x004a312f in revalidate_ukey (udpif=0x38a5260,
>> > ukey=0x7ff0fc015910, stats=0x7ff11d668260,
>> > odp_actions=0x7ff11d66a3d0, reval_seq=25145760,
>> > recircs=0x7ff11d66a3b0) at ofproto/ofproto-dpif-upcall.c:2134
>> > #17 0x004a3d76 in revalidate (revalidator=0x4cdda08) at
>> > ofproto/ofproto-dpif-upcall.c:2428
>> > #18 0x004a0528 in udpif_revalidator (arg=0x4cdda08) at
>> > ofproto/ofproto-dpif-upcall.c:954
>> > #19 0x0058f811 in ovsthread_wrapper (aux_=0x55088a0) at
>> > lib/ovs-thread.c:682
>> > #20 0x7ff27549adc5 in start_thread () from
>> > /usr/lib64/libpthread.so.0
>> >
>> > Any idea about this?
>> > Thanks,
>> > Yunjian
>>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss