Re: [ovs-discuss] [openvswitch 2.7.90] testsuite: 2180 failed

[Joe Stringer]

Hi Nick,

Looks like there's another report of trouble with this test below.
Would you be able to take a look?

On 20 March 2017 at 07:44, Aynur Shakirov  wrote:
> For latest master the OVS build of deb package unsuccessfully ends because
> test "flush the fdb and mdb when topology changed" is fail. Test added to
> git in commit 427e9751f30067357262f58fdf5af55df4b6debf
>
> Env: Ubuntu 16.04.1 with latest updates, compiler is gcc 5.3.1, dpdk
> enabled.
>
> Log: http://paste.ubuntu.com/24215426/
>
> Thanks.
>
> --
> Sincerely,
> Aynur Shakirov, 26.
> TIONIX RUS.
> Planet Earth, Solar System, Milky Way.
>
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVS supported hardware switches

[Ben Pfaff]

This is good information to have.  Thanks Tony and Stephen.

I didn't know that Open Switch used anything from OVS other than
ovsdb-server.  Maybe I'll have a look sometime.

On Tue, Mar 21, 2017 at 12:21:37PM +1300, Tony van der Peet wrote:
> We use a dpif implementation (based very much on dpif-netdev) but have
> also strongly considered writing our own ofproto. So I would agree
> that keeping the ofproto layer would be a good thing. And keeping it
> in such a way as to make it possible to write a new one!
> 
> OpenSwitch is one project that have written their own ofproto (last
> time I looked) but they have a slightly different use of Open vSwitch
> anyway (they focus more on the reconfigure code than on doing anything
> with OpenFlow rules.
> 
> Tony
> 
> On Sat, Mar 18, 2017 at 7:44 PM, Stephen Bailey  wrote:
> > Yes, they implement of-proto providers.
> >
> > I guess we've seen a disjoint set of switches, which is not necessarily
> > surprising :-).
> >
> > What's the expectation for e.g. a P4 switch?  It seems the most natural
> > mapping is an OpenFlow-style pipeline (versus dpif).
> >
> > Admittedly, there are many other OpenFlow agents beside OVS (e.g. the P4
> > OpenFlow agent, etc etc), it just seems OVS is particularly important in
> > open source networking (especially data center) and maintaining a distinct
> > OpenFlow layer beneficial.
> >
> > That said, of course I wouldn't arm wrestle you over it if nobody else cares
> > :-).
> >
> > Steph
> >
> >
> > On Fri, Mar 17, 2017 at 11:24 PM, Ben Pfaff  wrote:
> >>
> >> Do you mean that these implementations have their own ofproto provider
> >> implementations, that is, that they do not use ofproto-dpif and instead
> >> implement a different ofproto_class as defined in
> >> ofproto/ofproto-provider.h?  That indeed would be news to me.  All of
> >> the switches that I am aware of instead implement a dpif provider, as
> >> defined in lib/dpif-provider.h.  The dpif provider interface in that
> >> file is valuable and not going away.
> >>
> >> On Fri, Mar 17, 2017 at 09:33:26AM +0800, Stephen Bailey wrote:
> >> > I think it would be unfortunate to drop ofproto.
> >> >
> >> > I can't speak to Allied's implementation, but all switch implementations
> >> > I
> >> > am aware of use ofproto, including several I have worked on.
> >> >
> >> > These implementations don't tend to get upstreamed.  However, I think
> >> > OVS
> >> > plays quite an important role as an (the?) OpenFlow reference
> >> > implementation.
> >> >
> >> > I'm not sure if we could accomplish it but if it would help provide some
> >> > mass against ofproto, perhaps we could get an implemention or two
> >> > upstreamed?
> >> >
> >> > Steph
> >> >
> >> >
> >> > On Mar 16, 2017 08:58, "Ben Pfaff"  wrote:
> >> >
> >> > > On Tue, Mar 14, 2017 at 05:26:28PM +1300, Tony van der Peet wrote:
> >> > > > >On Fri, Mar 10, 2017 at 11:14:55AM +0530, Shravan S K wrote:
> >> > > > >> We are looking to buy a few OpenFlow-enabled switches. What
> >> > > advantages can
> >> > > > >> be achieved by a hardware switch that also supports OVS?
> >> > > > >> And can a hardware openflow L2 switch perform L3,L4 based
> >> > > > >> openflow
> >> > > > >> forwarding - can I inspect L3,L4 layers and take a decision based
> >> > > > >> on
> >> > > them ?
> >> > > > >
> >> > > > >It's hard to tell.  No one ever comes to us and says that they base
> >> > > > >their switch on OVS.  You have to guess.
> >> > > >
> >> > > > For the record, Allied Telesis have a range of switches that use
> >> > > > OVS.
> >> > >
> >> > > Good to know.  Do these switches implement a dpif provider or an
> >> > > ofproto
> >> > > provider?  We're talking about dropping the ofproto provider layer, so
> >> > > it's an important question.
> >> > > ___
> >> > > discuss mailing list
> >> > > disc...@openvswitch.org
> >> > > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
> >> > >
> >
> >
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] incorrect tcp checksum - inner packet of vxlan tunnel

[Avi Cohen (A)]

Hello,
I'm running ovs-dpdk with vxlan tunnel
Setup like http://docs.openvswitch.org/en/latest/howto/userspace-tunneling/

I'm running iperf3 on the endpoints VMs - and I see incorrect TCP checksum at 
the server side (this is seen after vxlan decap) I don't think this is ovs-dpdk 
issue - since the tcp checksum is set in the inner packet (VM payload) , hence 
should be set by the VM.
Who can assist ?
Best regards
avi

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

[ovs-discuss] OVS and RSTP

[Erez Segev]

Hi,



I'd like to forward BPDUs transparently in the OVS environment.

Would it be possible to let the OVS Bridge do not process RSTP fames and 
instead treat them as special traffic and mark them with special VLAN in order 
to let the internal VM Linux bridges run RSTP (BPDU tunneling).

another option is to tag is as data traffic.



See the following scheme...





[cid:image001.png@01D2A15A.07134E40]





Thanks for your help,

Erez




Erez Segev

NFV System Engineer


T:

+972.3.9287393

M:

+972.50.7057393

E:

erez.se...@ecitele.com



www.ecitele.com

[cid:image001.png@01D0A206.A2B15AE0]




___

This e-mail message is intended for the recipient only and contains information 
which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received 
this 
transmission in error, please inform us by e-mail, phone or fax, and then 
delete the original 
and all copies thereof.
__
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] [openvswitch 2.7.90] testsuite: 2180 failed

[nickcooper-zhangtonghao]

Yes, thanks for your report. I try to find what might cause this.

Thanks.
Nick

> On Mar 21, 2017, at 7:12 AM, Joe Stringer  wrote:
> 
> Hi Nick,
> 
> Looks like there's another report of trouble with this test below.
> Would you be able to take a look?

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

Re: [ovs-discuss] OVS-DPDK

[Advith Nagappa]

It did not tell me anything:

*Mar 20 11:42:23  ovs-vsctl: ovs|1|vsctl|INFO|Called as ovs-vsctl
add-port br0 dpdk-p0 -- set Interface dpdk-p0 type=dpdk
options:dpdk-devargs=:00:0a.0*
*Mar 20 11:42:23  ovs-vswitchd[23906]: ovs|00042|bridge|WARN|could not open
network device dpdk-p0 (No such device)*
*Mar 20 11:42:23  ovs-vswitchd[23906]: ovs|00044|bridge|WARN|could not open
network device dpdk-p0 (No such device)*


A ./dpdk-devbind.py --status shows the below results, confirming device
binding

*Network devices using DPDK-compatible driver*
**
*:00:09.0 'Ethernet Controller X710 for 10GbE SFP+' drv=igb_uio
unused=i40e*
*:00:0a.0 'Ethernet Controller X710 for 10GbE SFP+' drv=igb_uio
unused=i40e*

*Network devices using kernel driver*
*===*
*:00:07.0 'XL710/X710 Virtual Function' if=ens7 drv=i40evf
unused=igb_uio *Active**

*Other network devices*
*=*
**

*Crypto devices using DPDK-compatible driver*
*===*
**

*Crypto devices using kernel driver*
*==*
**

*Other crypto devices*
**
**

But, I did notice a curious thing:

when I init OVS with dpdk, using:

ovs-vsctl --no-wait set Open_vSwitch . other_config:dpdk-init=true
ovs-vsctl --no-wait set Open_vSwitch . other_config:dpdk-socket-mem="1024,0"




*2017-03-21T03:14:01Z|7|dpdk|INFO|EAL ARGS: ovs-vswitchd --socket-mem
1024,0 -c 0x0001*
*EAL: Detected 5 lcore(s)*
*EAL: Probing VFIO support...*
*EAL: WARNING: cpu flags constant_tsc=yes nonstop_tsc=no -> using
unreliable clock cycles !*
*EAL: PCI device :00:07.0 on NUMA socket -1*
*EAL:   probe driver: 8086:154c net_i40e_vf*
*EAL: PCI device :00:09.0 on NUMA socket -1*
*EAL:   probe driver: 8086:1572 net_i40e*
*PMD: eth_i40e_dev_init(): FW 5.0 API 1.5 NVM 05.00.02 eetrack 80002284*
*EAL: PCI device :00:0a.0 on NUMA socket -1*
*EAL:   probe driver: 8086:1572 net_i40e*
*PMD: eth_i40e_dev_init(): FW 5.0 API 1.5 NVM 05.00.02 eetrack 80002284*


I was wondering if the probe driver for 09.0 and 0a.0 should have been
something like 'igb_uio'.. I am not sure if this is how it should be?

Appreciate your inputs.

Best Regards
Advith Nagappa

On Tue, Mar 21, 2017 at 3:33 AM, Ben Pfaff  wrote:

> On Tue, Mar 21, 2017 at 02:36:23AM +0100, Advith Nagappa wrote:
> > Hi,
> >
> > I have DPDK 16.11.1 and OVS 2.6.1, with 1 Gb Huge page/ and 2 NICs bound
> > with Igb_uio drivers.
> >
> > I run in to trouble while creating DPDK ports on the OVS bridge.
> >
> >
> > *ovs-vsctl add-port br0 dpdk-p1 -- set Interface dpdk-p1 type=dpdk*
> >
> > works perfectly fine.
> >
> > But,
> >
> > *ovs-vsctl add-port br0 dpdk-p0 -- set Interface dpdk-p0 type=dpdk
> > options:dpdk-devargs=:00:0a.0*
> >
> > gives an error:
> > ovs-vsctl: Error detected while setting up 'dpdk-p0'.  See ovs-vswitchd
> log
> > for details.
>
> What's in the log?
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] OVS-DPDK

[Advith Nagappa]

Hi,

I have DPDK 16.11.1 and OVS 2.6.1, with 1 Gb Huge page/ and 2 NICs bound
with Igb_uio drivers.

I run in to trouble while creating DPDK ports on the OVS bridge.


*ovs-vsctl add-port br0 dpdk-p1 -- set Interface dpdk-p1 type=dpdk*

works perfectly fine.

But,

*ovs-vsctl add-port br0 dpdk-p0 -- set Interface dpdk-p0 type=dpdk
options:dpdk-devargs=:00:0a.0*

gives an error:
ovs-vsctl: Error detected while setting up 'dpdk-p0'.  See ovs-vswitchd log
for details.

:00:0a.0 is correctly bound to igb_uio driver..

Any idea what the issue may be?

and what is the specific purpose of 'options:dpdk-devargs'?

Appreciate your response.

Best Regards
Advith Nagappa
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] High Priority Traffic Path (dscp) for DPDK-OvS

[Ali Volkan Atli]

Hi all

I need to specify a number of classes of service according to DSCP bits. Each 
class of service should be associated with a priority. For example: Packet A is 
sent with a DSCP value of 0 and packet B is sent with a value of 46; 0 has a 
lower priority than 46. Packet A arrives before packet B. If DPDK-OvS has been 
configured as such, Packet B will be transmitted before Packet A.

I know that hardware switches have been designed to ensure certain classes of 
traffic can be scheduled ahead of other classes, also kernel mode OvS has the 
similar behavior coming from Linux kernel (tc, qdisk etc..). However, does 
DPDK-OvS have the same behavior? In master branch, I could not find any kind of 
scheduler to achieve this behavior. 

Thanks in advance..

- Volkan
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVS-DPDK

[Ben Pfaff]

On Tue, Mar 21, 2017 at 02:36:23AM +0100, Advith Nagappa wrote:
> Hi,
> 
> I have DPDK 16.11.1 and OVS 2.6.1, with 1 Gb Huge page/ and 2 NICs bound
> with Igb_uio drivers.
> 
> I run in to trouble while creating DPDK ports on the OVS bridge.
> 
> 
> *ovs-vsctl add-port br0 dpdk-p1 -- set Interface dpdk-p1 type=dpdk*
> 
> works perfectly fine.
> 
> But,
> 
> *ovs-vsctl add-port br0 dpdk-p0 -- set Interface dpdk-p0 type=dpdk
> options:dpdk-devargs=:00:0a.0*
> 
> gives an error:
> ovs-vsctl: Error detected while setting up 'dpdk-p0'.  See ovs-vswitchd log
> for details.

What's in the log?
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] [openvswitch 2.7.90] testsuite: 2180 failed

[Aynur Shakirov]

For latest master the OVS build of deb package unsuccessfully ends 
because test "flush the fdb and mdb when topology changed" is fail. Test 
added to git in commit 427e9751f30067357262f58fdf5af55df4b6debf


Env: Ubuntu 16.04.1 with latest updates, compiler is gcc 5.3.1, dpdk 
enabled.


Log: http://paste.ubuntu.com/24215426/

Thanks.

--
Sincerely,
Aynur Shakirov, 26.
TIONIX RUS.
Planet Earth, Solar System, Milky Way.

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

[ovs-discuss] in-band control traffic port

[蘇于倫]

Hi everyone,

Using in-band control, I've observed by Wireshark that the OFPT_HELLO
packet is captured
on one interface(ethX added to OVS bridge). Originally, I thought that all
of the ports of the
bridge direct the control traffic. The reason is that in in-band.c, the
hidden flow only specify
the MAC and/or IP address for match field but not port.

It turned out that my original thought is wrong since only one port is used
for control traffic
based on my Wireshark observation. My question is:
Does it make sense to have control traffic go through every
interface(port) ?
This way, the control plane might sustain better if the only
control-traffic port is down?

I've also done an experiment on turning off the control-traffic port, and
the result shows
that OVS spends around 10s to re-connect to the same controller with
OFPT_HELLO
message observed another interface.

Thanks for your help!
Ethan
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] OVS benchmark for kernel datapath module

[Danish Sattar]

Hi everyone,

I'm doing benchmark for the OVS kernel datapath module. i'm trying to see
the effect of different packet sizes, data rates and hardware on the
performance. i'm wondering if there are similar benchmarks available or if
any relevant information is available.

Thanks
*Best Regards*
*Danish Sattar*
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] OVS/DPDK STT Support

[Luca Salvatore via discuss]

We are playing with OVS/DPDK and have noticed that STT does not seem to be
supported in userspace.  Wondering if anyone happens to be working on
implementing this or has any suggestions for making it work

Testing on OVS 2.7.9 and DPDK 16.11


thanks
Luca.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss