Re: [ovs-discuss] ovsdb-client connection refused

[Flavio Leitner]

On Fri, 30 Dec 2016 14:59:27 +0530
Shravan S K  wrote:

> Hello,
> 
> set up : 2 machines running OVS 2.5.0.
> 
> m1 - 192.168.20.1
> m2 - 192.168.20.2
> 
> On m2 ->
> $ sudo ovs-vsctl set-manager tcp:192.168.20.1:6640
> $ sudo ovs-vsctl show
> 38bc233b-7431-4aad-aefd-9155aff54ad4
> Manager "tcp:192.168.20.1:6640"
> ovs_version: "2.5.0"
> 
> On m1 ->
> $ sudo ovsdb-client -v list-dbs tcp:192.168.20.2:6640
> 2016-12-30T09:23:13Z|1|poll_loop|DBG|wakeup due to 0-ms timeout
> 2016-12-30T09:23:13Z|2|poll_loop|DBG|wakeup due to
> [POLLOUT][POLLERR][POLLHUP] on fd 3 (192.168.20.2:36486<->) at
> ../lib/stream-fd.c:151
> ovsdb-client: failed to connect to "tcp:192.168.20.2:6640" (Connection
> refused)

In the first command you are telling to connect to the manager
using tcp at 192.168.20.1 port 6640 where you actually want to
to listen for a connection on that port, i.e.:

# ovs-vsctl set-manager ptcp:6640

-- 
Flavio

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

Re: [ovs-discuss] OVS bridge absorbing ARP replies

[Flavio Leitner]

On Thu, 29 Dec 2016 20:36:05 -0500
Yuanjun Yao  wrote:

> Hi all,
> 
> My network topology is host1(eth1:192.168.1.2)—(eth2:192.168.1.1)host2. I
> added an OVS bridge on host2 and added eth2 as a port. I configured the ip
> address via SDN controller. I could ping from host 1 to host2, but failed
> the other way.
> 
> My configuration commands on host2 are:
> 
> #ovs-vsctl add-br ovsbr1
> 
> #ovs-vsctl add-port ovsbr1 eth2
> 
> Then I set the ip address of ovsbr1 via SDN controller. I can ping from
> host1 to 192.168.1.1. But I can't ping from host 2 to host1. The reason is
> that host2 can't process ARP replies from host1. The result of "arp" shows
> that host 2 doesn't know the mac address of host1.
> 
> I used tcpdump to capture the packets, it shows that ARP replies packets
> from are received at eth2. The result of "ovs-ofctl dump-flows ovsbr1"
> shows that arp replies are matched with the rule whose action is normal, I
> also tried to add a flow that matches the arp replies and its action is
> "Local". None of this works.

You could try to tcpdump the ovsbr1 where the IP address is and see
if the ARP packets are getting there.  It sounds like a firewall issue.

-- 
Flavio

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

Re: [ovs-discuss] OVS bridge absorbing ARP replies

[Flavio Leitner]

On Fri, 30 Dec 2016 17:49:56 -0500
Yuanjun Yao  wrote:

> Hi Flavio,
> 
> Thanks for your reply. I might misconfigured OVS bridge. I forgot to remove
> the IP address from the original interface, that might caused the problem.

Glad to know that you found the problem.
-- 
Flavio

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

Re: [ovs-discuss] How do I push data from Open vSwitch to connected controllers?

[Flavio Leitner]

On Wed, 4 Jan 2017 10:43:58 +1100
Dzuy Pham <pham.d...@gmail.com> wrote:

> I am currently gathering the statistics live and want the switch to push
> them to the controller when a threshold has been met.

Interesting, well perhaps you could change connmgr_run() which
manages all connections to issue the stats reply when it is convenient?

connmgr_run(struct connmgr *mgr,
void (*handle_openflow)(struct ofconn *,
const struct ofpbuf *ofp_msg))
[...]
LIST_FOR_EACH_SAFE (ofconn, next_ofconn, node, >all_conns) {
ofconn_run(ofconn, handle_openflow);
}
[...]

you might need to change connmgr_wait() as well to wake up properly.

That's where I would start looking at :)
Flavio

> 
> On Tue, Jan 3, 2017 at 1:45 PM, Gmail <pham.d...@gmail.com> wrote:
> 
> > I am currently gathering the statistics live and want to push them only
> > when a threshold has been met.
> >
> >
> > On 3/01/2017 2:46 AM, Flavio Leitner wrote:
> >  
> >> May I ask why you don't want the controller to issue a Request?
> >>  
> >
> >  



-- 
Flavio

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

Re: [ovs-discuss] how many CPU cannot allocate for PMD thread?

[Flavio Leitner]

On Tue, 19 Sep 2017 13:43:25 +0800
Sun Paul <paul...@gmail.com> wrote:

> Hi
> 
> below is the output. currently, I am only able to set to use two CPU for PMD.


I was referring to the output of
ovs-vsctl get Open_vSwitch . other_config

fbl

> 
> # ovs-vsctl show
> ea7f2b40-b7b3-4f11-a81f-cf25a56f8172
> Bridge "gtp1"
> Port "dpdk0"
> Interface "dpdk0"
> type: dpdk
> options: {dpdk-devargs=":04:00.2", n_rxq="4"}
> Port "gtp1"
> Interface "gtp1"
> type: internal
> Port "dpdk1"
> Interface "dpdk1"
>     type: dpdk
> options: {dpdk-devargs=":04:00.3", n_rxq="4"}
> 
> 
> 
> On Tue, Sep 19, 2017 at 4:09 AM, Flavio Leitner <f...@sysclose.org> wrote:
> > On Mon, 18 Sep 2017 16:51:33 +0800
> > Sun Paul <paul...@gmail.com> wrote:
> >  
> >> Hi
> >>
> >> I have two interfaces mapped to DPDK, and run the OVS on top of it. I
> >> tried to set the cpu mask, but I cannot only allocate more than 2 CPU
> >> for pmd thread. any idea?
> >>
> >> # /usr/local/bin/ovs-appctl dpif-netdev/pmd-rxq-show
> >> pmd thread numa_id 0 core_id 1:
> >> isolated : false
> >> port: dpdk0 queue-id: 0
> >> pmd thread numa_id 0 core_id 2:
> >> isolated : false
> >> port: dpdk1 queue-id: 0  
> >
> > Could you post the DPDK configuration and what do you want?
> >
> > Thanks,
> > --
> > Flavio
> >  



-- 
Flavio

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

Re: [ovs-discuss] how many CPU cannot allocate for PMD thread?

[Flavio Leitner]

On Fri, 22 Sep 2017 15:02:20 +0800
Sun Paul  wrote:

> hi
> 
> we have tried on that. e.g. if we set to 0x22, we still only able to
> see 2 cpu is in 100%, why?

Because that's what you told OVS to do.
The mask 0x22 is 0010 0010 and each '1' there represents a CPU.

-- 
Flavio

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

Re: [ovs-discuss] how many CPU cannot allocate for PMD thread?

[Flavio Leitner]

On Mon, 18 Sep 2017 16:51:33 +0800
Sun Paul  wrote:

> Hi
> 
> I have two interfaces mapped to DPDK, and run the OVS on top of it. I
> tried to set the cpu mask, but I cannot only allocate more than 2 CPU
> for pmd thread. any idea?
> 
> # /usr/local/bin/ovs-appctl dpif-netdev/pmd-rxq-show
> pmd thread numa_id 0 core_id 1:
> isolated : false
> port: dpdk0 queue-id: 0
> pmd thread numa_id 0 core_id 2:
> isolated : false
> port: dpdk1 queue-id: 0

Could you post the DPDK configuration and what do you want?

Thanks,
-- 
Flavio

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

Re: [ovs-discuss] how many CPU cannot allocate for PMD thread?

[Flavio Leitner]

On Wed, 20 Sep 2017 09:13:55 +0800
Sun Paul <paul...@gmail.com> wrote:

> sorry about that
> 
> # ovs-vsctl get Open_vSwitch . other_config
> {dpdk-init="true", n-dpdk-rxqs="2", pmd-cpu-mask="0x6"}

Have you tried to change pmd-cpu-mask? Because that is mask of bits
representing the CPUs you allow PMDs to be created.  In this case,
you are saying '0x6' (binary mask: 0110), so only two CPUs.

Also check ovs-vswitchd.conf.db(5) man-page:

   other_config : pmd-cpu-mask: optional string
  Specifies  CPU  mask for setting the cpu affinity of PMD (Poll 
Mode
  Driver) threads. Value should be in the form of hex string, 
similar
  to  the  dpdk  EAL ’-c COREMASK’ option input or the ’taskset’ 
mask
  input.

  The lowest order bit corresponds to the first CPU core. A  set  
bit
  means  the corresponding core is available and a pmd thread will 
be
  created and pinned to it. If the input does not  cover  all  
cores,
  those uncovered cores are considered not set.

  If not specified, one pmd thread will be created for each numa 
node
  and pinned to any available core on the numa node by default.

fbl

> 
> On Tue, Sep 19, 2017 at 8:02 PM, Flavio Leitner <f...@sysclose.org> wrote:
> > On Tue, 19 Sep 2017 13:43:25 +0800
> > Sun Paul <paul...@gmail.com> wrote:
> >  
> >> Hi
> >>
> >> below is the output. currently, I am only able to set to use two CPU for 
> >> PMD.  
> >
> >
> > I was referring to the output of
> > ovs-vsctl get Open_vSwitch . other_config
> >
> > fbl
> >  
> >>
> >> # ovs-vsctl show
> >> ea7f2b40-b7b3-4f11-a81f-cf25a56f8172
> >> Bridge "gtp1"
> >> Port "dpdk0"
> >> Interface "dpdk0"
> >> type: dpdk
> >> options: {dpdk-devargs=":04:00.2", n_rxq="4"}
> >> Port "gtp1"
> >> Interface "gtp1"
> >> type: internal
> >> Port "dpdk1"
> >> Interface "dpdk1"
> >> type: dpdk
> >> options: {dpdk-devargs=":04:00.3", n_rxq="4"}
> >>
> >>
> >>
> >> On Tue, Sep 19, 2017 at 4:09 AM, Flavio Leitner <f...@sysclose.org> wrote: 
> >>  
> >> > On Mon, 18 Sep 2017 16:51:33 +0800
> >> > Sun Paul <paul...@gmail.com> wrote:
> >> >  
> >> >> Hi
> >> >>
> >> >> I have two interfaces mapped to DPDK, and run the OVS on top of it. I
> >> >> tried to set the cpu mask, but I cannot only allocate more than 2 CPU
> >> >> for pmd thread. any idea?
> >> >>
> >> >> # /usr/local/bin/ovs-appctl dpif-netdev/pmd-rxq-show
> >> >> pmd thread numa_id 0 core_id 1:
> >> >> isolated : false
> >> >> port: dpdk0 queue-id: 0
> >> >> pmd thread numa_id 0 core_id 2:
> >> >> isolated : false
> >> >> port: dpdk1 queue-id: 0  
> >> >
> >> > Could you post the DPDK configuration and what do you want?
> >> >
> >> > Thanks,
> >> > --
> >> > Flavio
> >> >  
> >
> >
> >
> > --
> > Flavio
> >  



-- 
Flavio

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

Re: [ovs-discuss] How can I OVS run in multi-core?

[Flavio Leitner]

On Thu, 31 Aug 2017 16:04:22 +0900
Heung Sik Choi  wrote:

> Hi,
> 
> I want to measure the performance of OVS in multi core.
> 
> I have a server on two Xeon 2630 v2 (NUMA) with 4 dual port 10GbE NIC. the
> server with 12 cores and 8 physical ports run OVS. 4ports are for receiving
> 40Gbps traffic and the other 4 ports are for sending 40Gbps traffic.
> 
> I use DPDK pktgen on other machine to make intensive traffic. using this
> maching, I sent 12 type flow traffic to OVS server. At this experiment I
> expected that OVS run in using 12 cores fully. However, It didn't work .

In order to have multiple CPUs processing packets in parallel with
the kernel datapath, you need multiple queues with their interrupts
spread among all relevant CPUs.  And in order to the NIC to spread
the traffic to different queues, you need different streams (5-tuple).
That is called RSS.

For example, stream A would go to queue#1 which is mapped to CPU#1 and
stream B would go to queue#2 which is mapped to CPU#2 and so on.

That is how Linux kernel works in general (as standalone NIC, or using
Linux bridge or OVS). Here is a doc explaining it in more details:
https://www.kernel.org/doc/Documentation/networking/scaling.txt

-- 
Flavio

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

Re: [ovs-discuss] quad port X710 rNDC (Dell) make KVM host br0 OVS (2.5.0) port lose connection

[Flavio Leitner]

On Thu, 31 Aug 2017 07:12:43 +
"Jayakumar, Muthurajan"  wrote:

> Dear team,
> Can I please request if any one of you have seen similar observation please.
> Kindly requesting to share your suggestion please.
> 
> Following is the observation:
> 
> quad port X710 rNDC (Dell) make KVM host br0 OVS (2.5.0) port lose connection
> 
> Background:
> 
> We are introducing quad port Intel X710 rNDC to all Dell 14G platform. We 
> make all eth0-eth3 of X710 (i40e driver 2.0.23, FW 6.00) as br0 uplink bond 
> of KVM OVS, and we have observed periodic network connection loss (ping 
> unreachable) on the br0 interface.
> 
> 
> Attached is one of node's OVS config & network port info. The AHV KVM host is:
> CentOS release 6.8 (Final)
> 4.4.26-1.el6.nutanix.20160925.83.x86_64
> From ovs-vsctl, eth0 is active OVS upstream port, eth1 is standby OVS port.
> Bridge "br0"
> Port "br0"
> Interface "br0"
> type: internal
> Port "br0-dhcp"
> Interface "br0-dhcp"
> type: vxlan
> options: {key="1", remote_ip="10.211.56.93"}
> Port "br0-up"
> Interface "eth1"
> Interface "eth3"
> Interface "eth0"
> Interface "eth2"
> Port "tap0"
> tag: 0
> Interface "tap0"
> Port "vnet0"
> Interface "vnet0"
> Port "br0-arp"
> Interface "br0-arp"
> type: vxlan
> options: {key="1", remote_ip="192.168.5.2"}
> ovs_version: "2.5.0"
>  br0-up 
> bond_mode: active-backup
> bond may use recirculation: no, Recirc-ID : -1
> bond-hash-basis: 0
> updelay: 0 ms
> downdelay: 0 ms
> lacp_status: off
> active slave mac: 24:6e:96:47:6d:0c(eth1)
> slave eth0: enabled
> may_enable: true
> slave eth1: enabled
> active slave
> may_enable: true
> slave eth2: disabled
> may_enable: false
> slave eth3: disabled
> may_enable: false
> 
> However, eth1 (port 1) has much more tx/rx traffic than eth0 (port3) per 
> ovs-ofctl dump, why?

Because eth1 is the active slave? So it will do all the TX/RX for
the br-up port.


> And pkt drop is on br0 uplink bond port & tap0 VM vnic port:
> ovs-ofctl dump-ports-desc br0
> -
> OFPST_PORT_DESC reply (xid=0x2):
> 1(eth1): addr:24:6e:96:47:6d:0c config: 0 state: 0 current: 10GB-FD 
> advertised: FIBER supported: 10GB-FD FIBER AUTO_PAUSE speed: 1 Mbps now, 
> 1 Mbps max
> 2(eth3): addr:24:6e:96:47:6d:10 config: 0 state: LINK_DOWN advertised: 1GB-FD 
> 10GB-FD AUTO_NEG supported: 1GB-FD 10GB-FD AUTO_NEG AUTO_PAUSE speed: 0 Mbps 
> now, 1 Mbps max
> 3(eth0): addr:24:6e:96:47:6d:0a config: 0 state: 0 current: 10GB-FD 
> advertised: FIBER supported: 10GB-FD FIBER AUTO_PAUSE speed: 1 Mbps now, 
> 1 Mbps max
> 4(eth2): addr:24:6e:96:47:6d:0e config: 0 state: LINK_DOWN advertised: 1GB-FD 
> 10GB-FD AUTO_NEG supported: 1GB-FD 10GB-FD AUTO_NEG AUTO_PAUSE speed: 0 Mbps 
> now, 1 Mbps max
> 5(vnet0): addr:fe:6b:8d:80:5c:a8 config: 0 state: 0 current: 10MB-FD COPPER 
> speed: 10 Mbps now, 0 Mbps max
> 6(br0-arp): addr:a6:3e:f0:db:76:c6 config: NO_FLOOD state: 0 speed: 0 Mbps 
> now, 0 Mbps max
> 7(br0-dhcp): addr:62:4d:cc:2f:33:b4 config: NO_FLOOD state: 0 speed: 0 Mbps 
> now, 0 Mbps max
> 37(tap0): addr:4a:37:5e:99:48:b7 config: 0 state: 0 current: 10MB-FD COPPER 
> speed: 10 Mbps now, 0 Mbps max
> LOCAL(br0): addr:24:6e:96:47:6d:0a config: 0 state: 0 speed: 0 Mbps now, 0 
> Mbps max
> ovs-ofctl dump-ports br0
> 
> OFPST_PORT reply (xid=0x2): 9 ports
> port LOCAL: rx pkts=2908711, bytes=942823314, drop=3031, errs=0, frame=0, 
> over=0, crc=0 tx pkts=2527350, bytes=909830850, drop=0, errs=0, coll=0

This is br0. Is it up or down? If it's down, the broadcasts for that port
will be dropped and accounted.


> port 37: rx pkts=7, bytes=412, drop=0, errs=0, frame=0, over=0, crc=0 tx 
> pkts=16, bytes=1666, drop=50414, errs=0, coll=0

Hard to tell without more info, like flow table and traffic. You might tcpdump
in the host and in the guest to see more, perhaps.

-- 
Flavio

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

Re: [ovs-discuss] ct_state and tcp sessions

[Flavio Leitner]

On Fri, 1 Sep 2017 14:33:58 -0600
Sterdnot Shaken  wrote:

> *OVS version: 2.70*
> 
> Howdy!
> 
> *Goal:* instantiate a flow(s) based on completion of tcp 3-way handshake
> and have those flows live ONLY as long as the respective tcp session
> exists. Once the tcp session has ended, I want the flow(s) to be removed. I
> don't want the flows to be removed if the respective hosts stop talking for
> whatever reason for say 5 minutes. They would be removed only in the event
> the tcp session is terminated.
> 
> Can I use ct_state and associated conn-track to accomplish this?

You can't control conntrack timeouts.

> Any ideas?

Well, I don't know if I got that right, but I suggest to look at
the documentation of ovs-ofctl searching for action ``learn´´.

-- 
Flavio

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

Re: [ovs-discuss] hardware offloading in ovs-2.8

[Flavio Leitner]

On Thu, 9 Nov 2017 18:07:05 +0800 (CST)
王嵘 <rong.w...@easystack.cn> wrote:

> hi,
> I rpmbuild  the ovs-dpdk by myself, and the "config/common_base" :
> CONFIG_RTE_LIBRTE_BNX2X_PMD=y
> CONFIG_RTE_LIBRTE_BNX2X_DEBUG=y
> CONFIG_RTE_LIBRTE_BNX2X_DEBUG_INIT=y
> CONFIG_RTE_LIBRTE_BNX2X_DEBUG_RX=y
> CONFIG_RTE_LIBRTE_BNX2X_DEBUG_TX=y
> CONFIG_RTE_LIBRTE_BNX2X_MF_SUPPORT=y
> CONFIG_RTE_LIBRTE_BNX2X_DEBUG_PERIODIC=y
> 
> then ,I build the rpm of dpdk/dpdk-devel，and installed the 2 rpms to rpmbuild 
>  the ovs-dpdk。
> when I used the ovs-dpdk with the bcm-NIC, there comes the error：
> 
> here is the error in "/var/log/openvswitch/ovs-vswitchd.log"
> 2017-11-09T09:28:30.038Z|16773336|dpdk|INFO|EAL: PCI device :20:00.1 on 
> NUMA socket 0
> 2017-11-09T09:28:30.038Z|16773337|dpdk|INFO|EAL:   probe driver: 14e4:168e 
> net_bnx2x
> 2017-11-09T09:28:30.038Z|16773338|dpdk|WARN|EAL: Requested device 
> :20:00.1 cannot be used
> 2017-11-09T09:28:30.038Z|16773339|dpdk|ERR|EAL: Driver cannot attach the 
> device (:20:00.1)
> 2017-11-09T09:28:30.038Z|16773340|netdev_dpdk|WARN|Error attaching device 
> ':20:00.1' to DPDK
> 2017-11-09T09:28:30.038Z|16773341|netdev|WARN|dpdk-eth2: could not set 
> configuration (Invalid argument)


Looks like DPDK has the pmd enabled and has identified the device.
Did you bind the NIC to the VFIO driver before start OVS?


> And, my NIC firmware is :
> [root@node-4 ~]# ethtool -i eth2
> driver: bnx2x
> version: 1.712.30-0
> firmware-version: bc 7.0.49
> expansion-rom-version:
> bus-info: :20:00.1
> supports-statistics: yes
> supports-test: yes
> supports-eeprom-access: yes
> supports-register-dump: yes
> supports-priv-flags: yes
> 
> 
> Does the fm version not satisfies ? or some other reasons ?

I don't know about FW versions.
fbl


> 
> 
> 
> 
> 
> 
> 在 2017-11-08 21:28:01，"Flavio Leitner" <f...@sysclose.org> 写道：
> >On Wed, 8 Nov 2017 11:15:00 +0800 (CST)
> >王嵘 <rong.w...@easystack.cn> wrote:
> >  
> >> For now, I 'm using the "NetXtreme II BCM57810 10 Gigabit Ethernet 168e".
> >> Another question,  I found  ovs-dpdk can't bind this NIC. But I find there 
> >> is the support code for 57810 in the DPDK Bnx2x.
> >> I'm puzzled.
> >> Can you tell me whether  ovs-dpdk support this NIC?
> >> 
> >> Thanks very much!  
> >
> >You need to check that with your software provider. If you compiled
> >manually, then you need to check the options/config used to build DPDK.
> >
> >fbl
> >
> >  
> >> 在 2017-11-08 09:11:25，"Ben Pfaff" <b...@ovn.org> 写道：  
> >> >On Tue, Nov 07, 2017 at 03:49:06PM +0800, 王嵘 wrote:
> >> >> Hi,
> >> >> I'm using ovs-dpdk（ovs2.8/dpdk17.05.2), and I want to use the offload 
> >> >> feature. But I dont know how to enable it?
> >> >> As is represented in the release note 2.8:
> >> >> 
> >> >>- Addexperimental support for hardware offloading
> >> >>  * HW offloading is disabled by default.
> >> >> 
> >> >>  * HW offloading is done through the TC interface.
> >> >
> >> >Do you have a supported NIC?  This feature is currently for a particular
> >> >model of Mellanox NICs.
> >
> >
> >
> >-- 
> >Flavio
> >  



-- 
Flavio

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

Re: [ovs-discuss] (no subject)

[Flavio Leitner]

On Wed, 8 Nov 2017 15:17:46 +0530
Neelakantam Gaddam  wrote:

> Hi All,
> 
> I want to configure the flows for vlan access ports with connection
> tracking. Is there any example in the ovs source where can I find these
> configurations.
> I would appreciate if any one share the example configuration or point me
> to the information link.

http://openvswitch.org/support/dist-docs/ovs-ofctl.8.txt
and look for the Flow Syntax section.

Also:
http://openvswitch.org/support/dist-docs/ovs-fields.7.txt

Here is the tutorial:
http://docs.openvswitch.org/en/latest/tutorials/ovs-advanced/#implementing-table-1-vlan-input-processing

HTH,
-- 
Flavio

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

Re: [ovs-discuss] Problem on OpenVSwitch 2.8.1

[Flavio Leitner]

On Tue, 31 Oct 2017 16:41:53 +0100
Fabio Zingaretti  wrote:

> Dear support,
> I’m testing OpenVSwitch version 2.8.1 on my infrastructure using CentOS7 , 
> but I’m having any problem , in particular: 
> 
> 1) I configured the VXLAN but if I perform a reboot of the server I lose the 
> VXLAN configuration and I have to perform again the configuration 

Look at /usr/share/doc/openvswitch/README.RHEL.rst to
see how to configure it in a persistent way.

> 2) I see the following error inside /var/log/messages :  “kernel: 
> openvswitch: ovs: recursion limit reached on datapath ovs-system, probable 
> configuration error”  but the configuration works properly…

I will be hard for us to help without more info.  There was a fix to control
how many recursions could happen, and your setup is most probably hitting it.

It can crash the kernel if you go beyond, see:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b064d0d88ae5280c7e878f79d0c9a8e2876a4d14


> I replicated the configuration that I used with old version of  OpenVSwitch. 

-- 
Flavio

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

Re: [ovs-discuss] [ovs-dpdk] how to link between guest vNIC and dpdkvhost socket

[Flavio Leitner]

On Wed, 25 Oct 2017 07:36:13 +
"Xu, Rongjie (NSB - CN/Hangzhou)"  wrote:

> Hi,
> 
> I have one OpenStack environment with OVS-DPDK (manually installed). I 
> success to launch two VMs on two separate compute node with vhostuser 
> interface type. But I cannot ping from one to another. I found there are even 
> no packets in the local 'br-int' bridge (where dpdkvhostuser interface is 
> attached). My guess is the link between guest vNIC and dpdkvhost socket at 
> host side is somehow broken, but I do not know how to proceed. Anyone any 
> suggestions?


Most probably you forgot to share the memory between host and guest.
in the VM xml:

E.g.:
  

  

  
...

  

...

fbl

> Compute0:
> Bridge br-int
> Controller "tcp:127.0.0.1:6633"
> is_connected: true
> fail_mode: secure
> Port "vhu2aae3928-3c"
> tag: 1
> Interface "vhu2aae3928-3c"
> type: dpdkvhostuser
> root@compute0:~# file /var/run/openvswitch/vhu2aae3928-3c
> /var/run/openvswitch/vhu2aae3928-3c: socket
> 
> Compute1:
> Bridge br-int
> Controller "tcp:127.0.0.1:6633"
> is_connected: true
> fail_mode: secure
> Port "vhuca25b420-6d"
> tag: 1
> Interface "vhuca25b420-6d"
>type: dpdkvhostuser
> root@compute1:~# file /var/run/openvswitch/vhuca25b420-6d
> /var/run/openvswitch/vhuca25b420-6d: socket
> 
> 
> When I ping, I even does not find ARP packets in the br-int flow tables.
> root@compute0:~# ovs-ofctl dump-flows br-int | grep "in_port=3"
> cookie=0xb177d87a58ae18fe, duration=1927.889s, table=0, n_packets=0, 
> n_bytes=0, idle_age=1927, priority=10,icmp6,in_port=3,icmp_type=136 
> actions=resubmit(,24)
> cookie=0xb177d87a58ae18fe, duration=1927.886s, table=0, n_packets=0, 
> n_bytes=0, idle_age=1927, priority=10,arp,in_port=3 actions=resubmit(,24)
> cookie=0xb177d87a58ae18fe, duration=1927.893s, table=0, n_packets=0, 
> n_bytes=0, idle_age=1927, priority=9,in_port=3 actions=resubmit(,25)
> cookie=0xb177d87a58ae18fe, duration=1927.891s, table=24, n_packets=0, 
> n_bytes=0, idle_age=1927, 
> priority=2,icmp6,in_port=3,icmp_type=136,nd_target=fe80::f816:3eff:fed3:2116 
> actions=NORMAL
> cookie=0xb177d87a58ae18fe, duration=1927.888s, table=24, n_packets=0, 
> n_bytes=0, idle_age=1927, priority=2,arp,in_port=3,arp_spa=192.168.100.13 
> actions=resubmit(,25)
> cookie=0xb177d87a58ae18fe, duration=1927.896s, table=25, n_packets=0, 
> n_bytes=0, idle_age=1927, priority=2,in_port=3,dl_src=fa:16:3e:d3:21:16 
> actions=NORMAL
> 
> root@compute0:~# ovs-ofctl show br-int
> OFPT_FEATURES_REPLY (xid=0x2): dpid:caf6709a034a
> n_tables:254, n_buffers:256
> capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP
> actions: output enqueue set_vlan_vid set_vlan_pcp strip_vlan mod_dl_src 
> mod_dl_dst mod_nw_src mod_nw_dst mod_nw_tos mod_tp_src mod_tp_dst
> 1(int-br0): addr:7e:de:e2:7b:2a:83
>  config: 0
>  state:  0
>  speed: 0 Mbps now, 0 Mbps max
> 2(patch-tun): addr:5a:2a:d3:f0:14:72
>  config: 0
>  state:  0
>  speed: 0 Mbps now, 0 Mbps max
> 3(vhu2aae3928-3c): addr:00:00:00:00:00:00
>  config: 0
>  state:  0
>  speed: 0 Mbps now, 0 Mbps max
> 
> Best Regards
> Xu Rongjie (Max)
> 



-- 
Flavio

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

Re: [ovs-discuss] OVS+DPDK

[Flavio Leitner]

On Fri, May 25, 2018 at 05:18:08PM -0400, Pedro Serrano wrote:
> Greetings,
> 
> My computer is setup using Ubuntu 18.04 with OVS 2.90 and dpdk 17.11.2-1.
>  I'm attempting to create a few virtual ports (type dkdkvhostuserclient) on
> my OVS bridge (datapath_type=netdev) and assign an IP addresses to them.
> 
> ovs-vsctl add-br ovdkibr1 -- set bridge ovdkibr1 datapath_type=netdev
> ovs-vsctl set Bridge ovdkibr1 stp_enable=false
> ovs-vsctl add-port ovdkibr1 ovdkibr1p1 -- set Interface ovdkibr1p1
> type=dpdkvhostuserclient mtu_request=8996
> ovs-vsctl add-port ovdkibr1 ovdkibr1p2 -- set Interface ovdkibr1p2
> type=dpdkvhostuserclient mtu_request=8996
> 
> I've noticed that those virtual devices are not visible in the kernel space
> (unlike type=tap or type=dpdk).   Since they are not visible to the kernel
> they can't be configured using the "ip address add" command.
> 
> Since the iproute2 tools can't see these devices, is there any way to
> assign IP addresses, VLANs, etc to these devices?

The bridge port is a tap device visible to the kernel and you could
add more ports of type=internal which will be the same thing.

However, we try to not mix the datapaths because it will slow down
both if packets are crossing from one to another.

-- 
Flavio

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

Re: [ovs-discuss] [ovs-dpdk] how to check link between guest vNIC and dpdkvhost socket

[Flavio Leitner]

On Thu, 26 Oct 2017 11:06:08 +0800
徐荣杰  wrote:

> Hi,
> 
> 
> 
> I do have the memAccess property as follows for both VM
> 
>
> 
>   
> 
>   
> 
>   
> 
> 
> 
>memAccess='shared'/>  
> 
>   


OK, then look if the socket path is correct.
Also if you don't have apparmor/selinux issues.
Look at the OVS logs and EAL initialization messages which might
give you a hint.  The qemu log is also important.

Usually the memory isn't shared or something is wrong that
the socket is not opened/functional for one side.

-- 
Flavio

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

Re: [ovs-discuss] [ovs-dpdk] how to check link between guest vNIC and dpdkvhost socket

[Flavio Leitner]

On Thu, 26 Oct 2017 02:29:16 +
"Xu, Rongjie (NSB - CN/Hangzhou)" <rongjie...@nokia-sbell.com> wrote:

> Hi,
> 
> I do have the memAccess property as follows for both VM
> 
>   
> 
> 
> 
>   
> 
>   


Yes, but that's only one part. You also need the memoryBacking section
to be hugepages.

fbl



> 
> Best Regards
> Xu Rongjie (Max)
> 
> -Original Message-
> From: ovs-discuss-boun...@openvswitch.org 
> [mailto:ovs-discuss-boun...@openvswitch.org] On Behalf Of Flavio Leitner
> Sent: Thursday, October 26, 2017 09:50
> To: Xu, Rongjie (NSB - CN/Hangzhou) <rongjie...@nokia-sbell.com>
> Cc: ovs-discuss@openvswitch.org
> Subject: Re: [ovs-discuss] [ovs-dpdk] how to link between guest vNIC and 
> dpdkvhost socket
> 
> On Wed, 25 Oct 2017 07:36:13 +
> "Xu, Rongjie (NSB - CN/Hangzhou)" <rongjie...@nokia-sbell.com> wrote:
> 
> > Hi,
> > 
> > I have one OpenStack environment with OVS-DPDK (manually installed). I 
> > success to launch two VMs on two separate compute node with vhostuser 
> > interface type. But I cannot ping from one to another. I found there are 
> > even no packets in the local 'br-int' bridge (where dpdkvhostuser interface 
> > is attached). My guess is the link between guest vNIC and dpdkvhost socket 
> > at host side is somehow broken, but I do not know how to proceed. Anyone 
> > any suggestions?  
> 
> 
> Most probably you forgot to share the memory between host and guest.
> in the VM xml:
> 
> E.g.:
>   
> 
>   
> 
>   
> ...
> 
>   
> 
> ...
> 
> fbl
> 
> > Compute0:
> > Bridge br-int
> > Controller "tcp:127.0.0.1:6633"
> > is_connected: true
> > fail_mode: secure
> > Port "vhu2aae3928-3c"
> > tag: 1
> > Interface "vhu2aae3928-3c"
> > type: dpdkvhostuser
> > root@compute0:~# file /var/run/openvswitch/vhu2aae3928-3c
> > /var/run/openvswitch/vhu2aae3928-3c: socket
> > 
> > Compute1:
> > Bridge br-int
> > Controller "tcp:127.0.0.1:6633"
> > is_connected: true
> > fail_mode: secure
> > Port "vhuca25b420-6d"
> > tag: 1
> > Interface "vhuca25b420-6d"
> >type: dpdkvhostuser
> > root@compute1:~# file /var/run/openvswitch/vhuca25b420-6d
> > /var/run/openvswitch/vhuca25b420-6d: socket
> > 
> > 
> > When I ping, I even does not find ARP packets in the br-int flow tables.
> > root@compute0:~# ovs-ofctl dump-flows br-int | grep "in_port=3"
> > cookie=0xb177d87a58ae18fe, duration=1927.889s, table=0, n_packets=0, 
> > n_bytes=0, idle_age=1927, priority=10,icmp6,in_port=3,icmp_type=136 
> > actions=resubmit(,24)
> > cookie=0xb177d87a58ae18fe, duration=1927.886s, table=0, n_packets=0, 
> > n_bytes=0, idle_age=1927, priority=10,arp,in_port=3 actions=resubmit(,24)
> > cookie=0xb177d87a58ae18fe, duration=1927.893s, table=0, n_packets=0, 
> > n_bytes=0, idle_age=1927, priority=9,in_port=3 actions=resubmit(,25)
> > cookie=0xb177d87a58ae18fe, duration=1927.891s, table=24, n_packets=0, 
> > n_bytes=0, idle_age=1927, 
> > priority=2,icmp6,in_port=3,icmp_type=136,nd_target=fe80::f816:3eff:fed3:2116
> >  actions=NORMAL
> > cookie=0xb177d87a58ae18fe, duration=1927.888s, table=24, n_packets=0, 
> > n_bytes=0, idle_age=1927, priority=2,arp,in_port=3,arp_spa=192.168.100.13 
> > actions=resubmit(,25)
> > cookie=0xb177d87a58ae18fe, duration=1927.896s, table=25, n_packets=0, 
> > n_bytes=0, idle_age=1927, priority=2,in_port=3,dl_src=fa:16:3e:d3:21:16 
> > actions=NORMAL
> > 
> > root@compute0:~# ovs-ofctl show br-int
> > OFPT_FEATURES_REPLY (xid=0x2): dpid:caf6709a034a
> > n_tables:254, n_buffers:256
> > capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP
> > actions: output enqueue set_vlan_vid set_vlan_pcp strip_vlan mod_dl_src 
> > mod_dl_dst mod_nw_src mod_nw_dst mod_nw_tos mod_tp_src mod_tp_dst
> > 1(int-br0): addr:7e:de:e2:7b:2a:83
> >  config: 0
> >  state:  0
> >  speed: 0 Mbps now, 0 Mbps max
> > 2(patch-tun): addr:5a:2a:d3:f0:14:72
> >  config: 0
> >  state:  0
> >  speed: 0 Mbps now, 0 Mbps max
> > 3(vhu2aae3928-3c): addr:00:00:00:00:00:00
> >  config: 0
> >  state:  0
> >  speed: 0 Mbps now, 0 Mbps max
> > 
> > Best Regards
> > Xu Rongjie (Max)
> >   
> 
> 
> 



-- 
Flavio

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

Re: [ovs-discuss] REDHAT: Route issue with dpdk-bond ports

[Flavio Leitner]

On Wed, Jan 17, 2018 at 10:25:36AM +, Vishal Deep Ajmera wrote:
> Hi Flavio,
> 
> I tried to look closer into ifup-ovs script particularly for OVSDPDKPort & 
> OVSDPDKBOND cases. 
> With the change given below (git diff) at the end OVSDPDKBOND case, I see 
> that the routes 
> are getting installed again after adding dpdkbond port to the bridge. Perhaps 
> the same fix 
> needs to be done for OVSDPDKPort case as well. I think we need to invoke 
> $OTHERSCRIPT
> (ifup-eth) for the bridge in each of the above cases.
> 
> Does this fix in ifup-ovs script makes sense ?  If you agree, I will post a 
> patch for review on 
> ovs-dev list.

What happens if you have two or more bonds or if we fix dpdk port too,
what happens when you have more than one?  I think you will see
errors/failures.

> 
> diff --git a/rhel/etc_sysconfig_network-scripts_ifup-ovs 
> b/rhel/etc_sysconfig_network-scripts_ifup-ovs
> index b95220a..132ed29 100755
> --- a/rhel/etc_sysconfig_network-scripts_ifup-ovs
> +++ b/rhel/etc_sysconfig_network-scripts_ifup-ovs
> @@ -202,6 +202,7 @@ case "$TYPE" in
> ovs-vsctl -t ${TIMEOUT} \
> -- --if-exists del-port "$OVS_BRIDGE" "$DEVICE" \
> -- add-bond "$OVS_BRIDGE" "$DEVICE" ${BOND_IFACES} 
> $OVS_OPTIONS ${IFACE_TYPES} ${OVS_EXTRA+-- $OVS_EXTRA}
> +   ${OTHERSCRIPT} $OVS_BRIDGE
> ;;
> *)
> echo $"Invalid OVS interface type $TYPE"
> 

-- 
Flavio

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

Re: [ovs-discuss] REDHAT: Route issue with dpdk-bond ports

[Flavio Leitner]

On Tue, Dec 26, 2017 at 08:31:49AM +, Vishal Deep Ajmera wrote:
> Hi,
> 
> On Red-Hat, kernel IP Routes are getting deleted whenever a dpdk-bond port is
> added to "netdev" type bridge.  I understand that when a DPDK port is added to
> ovs, the bridge port (LOCAL) is reconfigured with MAC address which requires
> IOCTL calls to bring the device down and up. This causes kernel to remove the
> routes.
> 
> Can someone please have a look and let me know what am I missing here ?

Hi Vishal,

I think when the interface goes down to change the MAC address, the
routes will go away.  The only way to to make sure the routes will
be restored is to change the initialization order.

In your case, br0 is initialized first, then dpdkbond0 which will
cause the issue.

The order is alphabetical, so try renaming br0 to something like
zbr0 to see if the bridge is reconfigured with the routes.

fbl

> Steps to reproduce the issue:
> 
> # Create the bridge in OVS.
> $ ifup br0
> 
> # Dump the routes
> $ ip route
> 11.2.0.0/24 dev br0 proto kernel scope link src 11.2.0.26
> 100.100.100.10 via 11.2.0.202 dev br0
> 100.100.100.20 via 11.2.0.201 dev br0
> 169.254.0.0/16 dev br0 scope link metric 1036
> 
> # Add DPDK Bond to bridge br0
> $ ifup dpdkbond0
> 
> # Dump the routes
> $ ip route
> 11.2.0.0/24 dev br0 proto kernel scope link src 11.2.0.26
> --> Other routes for br0 are missing.
> 
> Here are the ifcfg files for the bridge BR0 and DPDKBOND0 port along with
> static routes.
> =
> $ cat ifcfg-br0
> DEVICE=br0
> ONBOOT=yes
> HOTPLUG=no
> NM_CONTROLLED=no
> PEERDNS=no
> DEVICETYPE=ovs
> TYPE=OVSUserBridge
> BOOTPROTO=static
> IPADDR=11.2.0.26
> NETMASK=255.255.255.0
> OVS_EXTRA="set bridge br0 fail_mode=standalone"
> 
> $ cat ifcfg-dpdkbond0
> DEVICE=dpdkbond0
> ONBOOT=yes
> HOTPLUG=no
> NM_CONTROLLED=no
> PEERDNS=no
> DEVICETYPE=ovs
> TYPE=OVSDPDKBond
> OVS_BRIDGE=br0
> BOND_IFACES="dpdk0 dpdk1"
> OVS_OPTIONS="bond_mode=balance-tcp other_config:lacp-time=fast lacp=passive"
> 
> $ cat route-br0
> 100.100.100.10 via 11.2.0.201 dev br0
> 100.100.100.20 via 11.2.0.202 dev br0
> 
> =
> 
> Warm Regards,
> Vishal
> 

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


-- 
Flavio

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

Re: [ovs-discuss] Mempool issue for OVS 2.9

[Flavio Leitner]

On Fri, Jan 26, 2018 at 05:16:02PM +0300, Ilya Maximets wrote:
> On 26.01.2018 15:00, Stokes, Ian wrote:
> > Hi All,
> > 
> > Recently an issue was raised regarding the move from a single shared 
> > mempool model that was in place up to OVS 2.8, to a mempool per port model 
> > introduced in 2.9.
> > 
> > https://mail.openvswitch.org/pipermail/ovs-discuss/2018-January/046021.html
> > 
> > The per port mempool model was introduced in September 5th with commit 
> > d555d9bded to allow fine grain control on a per port case of memory usage.
> > 
> > In the 'common/shared mempool' model, ports sharing a similar MTU would all 
> > share the same buffer mempool (e.g. the most common example of this being 
> > that all ports are by default created with a 1500B MTU, and as such share 
> > the same mbuf mempool).
> > 
> > This approach had some drawbacks however. For example, with the shared 
> > memory pool model a user could exhaust the shared memory pool (for instance 
> > by requesting a large number of RXQs for a port), this would cause the 
> > vSwitch to crash as any remaining ports would not have the required memory 
> > to function. This bug was discovered and reported to the community in late 
> > 2016 
> > https://mail.openvswitch.org/pipermail/ovs-discuss/2016-September/042560.html.
> > 
> > The per port mempool patch aimed to avoid such issues by allocating a 
> > separate buffer mempool to each port.
> > 
> > An issue has been flagged on ovs-discuss, whereby memory dimensions 
> > provided for a given number of ports on OvS 2.6-2.8 may be insufficient to 
> > support the same number of ports in OvS 2.9, on account of the per-port 
> > mempool model without re-dimensioning extra memory. The effect of this is 
> > use case dependent (number of ports, RXQs, MTU settings, number of PMDs 
> > etc.) The previous 'common-pool' model was rudimentary in estimating the 
> > mempool size and was marked as something that was to be improved upon. The 
> > memory allocation calculation for per port model was modified to take the 
> > possible configuration factors mentioned into account.
> > 
> > It's unfortunate that this came to light so close to the release code 
> > freeze - but better late than never as it is a valid problem to be resolved.
> > 
> > I wanted to highlight some options to the community as I don't think the 
> > next steps should be taken in isolation due to the impact this feature has.
> > 
> > There are a number of possibilities for the 2.9 release.
> > 
> > (i) Revert the mempool per port patches and return to the shared mempool 
> > model. There are a number of features and refactoring in place on top of 
> > the change so this will not be a simple revert. I'm investigating what 
> > exactly is involved with this currently.
> 
> This looks like a bad thing to do. Shared memory pools has their own issues 
> and
> hides the real memory usage by each port. Also, reverting seems almost 
> impossible,
> we'll have to re-implement it from scratch.

Agreed.

> > (ii) Leave the per port mempool implementation as is, flag to users that 
> > memory requirements have increased. Extra memory may have to be provided on 
> > a per use case basis.
> 
> That's a good point. I prefer this option if possible.

I was told we have ways to handle this change outside of OVS which is
not ideal, but doable.

It would be nice to have a doc explaining how to estimate the new
amount of memory required though.

 
> > (iii) Reduce the amount of memory allocated per mempool per port. An RFC to 
> > this effect was submitted by Kevin but on follow up the feeling is that it 
> > does not resolve the issue adequately.
> 
> IMHO, we should not reduce the mempool size by hardcoding small value. 
> Different
> installations has their own requirements because of different numbers of HW 
> NICs
> and CPU cores. I beleive that 20-30K is a normal size per-port for now.
> 
> How about to add an upper limit for mempool size configurable in boot time?
> See below code for example (not tested):

Thanks for the quick patch.  I see two problems:
1) Existing environments might stop working after an upgrade due to
the insufficient memory.  In this case, this solution would help but
then one could simply increase the amount of hugepages and move on as
it requires manual intervention in the same way.

2) New installations would need to follow the new documentation and
not sure how this would help here.

My concern is that this is another tunable to consider and most
probably to be misused, unless we think the number of buffers is over
estimated now.


> ---
> diff --git a/lib/dpdk-stub.c b/lib/dpdk-stub.c
> index 3602180..ed54e06 100644
> --- a/lib/dpdk-stub.c
> +++ b/lib/dpdk-stub.c
> @@ -54,3 +54,9 @@ dpdk_vhost_iommu_enabled(void)

[...]

> > (iv) Introduce a feature to allow users to configure mempool as
> > shared or on a per port basis: This would be the best 

Re: [ovs-discuss] REDHAT: Route issue with dpdk-bond ports

[Flavio Leitner]

On Wed, Jan 17, 2018 at 09:17:07PM -0200, Flavio Leitner wrote:
> On Wed, Jan 17, 2018 at 04:35:01PM +, Vishal Deep Ajmera wrote:
> > > What happens if you have two or more bonds or if we fix dpdk port too, 
> > > what happens when you have more than one? 
> > >  I think you will see errors/failures.
> > 
> > I tried with two dpdk ports and I do see following print on console though 
> > it seem harmless and does not impact route table. Also, this happens only 
> > when bridge mac was unchanged by addition of new DPDK port. 
> > 
> > RTNETLINK answers: File exists
> > RTNETLINK answers: File exists
> > RTNETLINK answers: File exists
> 
> OK, what about this patch instead? It should fix the issue without the
> errors.  I have not tested.

BTW, I suggested earlier but maybe I wasn't clear.

Instead of adding networking configuration to the bridge's port, just
leave it alone with a name that doesn't bother you.

Then create an internal port with the name and the networking
configuration you need. It won't change its MAC and neither lose
the routes. They both will be tap devices anyways.

fbl


> 
> diff --git a/rhel/etc_sysconfig_network-scripts_ifup-ovs 
> b/rhel/etc_sysconfig_network-scripts_ifup-ovs
> index b95220a7f..b455e356e 100755
> --- a/rhel/etc_sysconfig_network-scripts_ifup-ovs
> +++ b/rhel/etc_sysconfig_network-scripts_ifup-ovs
> @@ -167,10 +167,17 @@ case "$TYPE" in
>   ;;
>   OVSDPDKPort)
>   ifup_ovs_bridge
> + BRIDGE_MAC_ORIG=$(get_hwaddr $OVS_BRIDGE)
>   ovs-vsctl -t ${TIMEOUT} \
>   -- --if-exists del-port "$OVS_BRIDGE" "$DEVICE" \
>   -- add-port "$OVS_BRIDGE" "$DEVICE" $OVS_OPTIONS \
>   -- set Interface "$DEVICE" type=dpdk ${OVS_EXTRA+-- 
> $OVS_EXTRA}
> + BRIDGE_MAC=$(get_hwaddr $OVS_BRIDGE)
> + # The bridge will change its MAC to be the lower one among all 
> its
> + # ports. Restore the configuration if that happens.
> + if [ "$BRIDGE_MAC_ORIG" != "$BRIDGE_MAC" ]; then
> + OVSINTF=${DEVICE} /sbin/ifup "$OVS_BRIDGE"
> + fi
>   ;;
>   OVSDPDKRPort)
>   ifup_ovs_bridge
> @@ -196,12 +203,19 @@ case "$TYPE" in
>   ;;
>   OVSDPDKBond)
>   ifup_ovs_bridge
> + BRIDGE_MAC_ORIG=$(get_hwaddr $OVS_BRIDGE)
>   for _iface in $BOND_IFACES; do
>   IFACE_TYPES="${IFACE_TYPES} -- set interface ${_iface} 
> type=dpdk"
>   done
>   ovs-vsctl -t ${TIMEOUT} \
>   -- --if-exists del-port "$OVS_BRIDGE" "$DEVICE" \
>   -- add-bond "$OVS_BRIDGE" "$DEVICE" ${BOND_IFACES} 
> $OVS_OPTIONS ${IFACE_TYPES} ${OVS_EXTRA+-- $OVS_EXTRA}
> + BRIDGE_MAC=$(get_hwaddr $OVS_BRIDGE)
> + # The bridge will change its MAC to be the lower one among all 
> its
> + # ports. Restore the configuration if that happens.
> + if [ "$BRIDGE_MAC_ORIG" != "$BRIDGE_MAC" ]; then
> + OVSINTF=${DEVICE} /sbin/ifup "$OVS_BRIDGE"
> + fi
>   ;;
>   *)
>   echo $"Invalid OVS interface type $TYPE"
> 
> -- 
> Flavio

-- 
Flavio

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

Re: [ovs-discuss] REDHAT: Route issue with dpdk-bond ports

[Flavio Leitner]

On Wed, Jan 17, 2018 at 04:35:01PM +, Vishal Deep Ajmera wrote:
> > What happens if you have two or more bonds or if we fix dpdk port too, 
> > what happens when you have more than one? 
> >  I think you will see errors/failures.
> 
> I tried with two dpdk ports and I do see following print on console though 
> it seem harmless and does not impact route table. Also, this happens only 
> when bridge mac was unchanged by addition of new DPDK port. 
> 
> RTNETLINK answers: File exists
> RTNETLINK answers: File exists
> RTNETLINK answers: File exists

OK, what about this patch instead? It should fix the issue without the
errors.  I have not tested.

diff --git a/rhel/etc_sysconfig_network-scripts_ifup-ovs 
b/rhel/etc_sysconfig_network-scripts_ifup-ovs
index b95220a7f..b455e356e 100755
--- a/rhel/etc_sysconfig_network-scripts_ifup-ovs
+++ b/rhel/etc_sysconfig_network-scripts_ifup-ovs
@@ -167,10 +167,17 @@ case "$TYPE" in
;;
OVSDPDKPort)
ifup_ovs_bridge
+   BRIDGE_MAC_ORIG=$(get_hwaddr $OVS_BRIDGE)
ovs-vsctl -t ${TIMEOUT} \
-- --if-exists del-port "$OVS_BRIDGE" "$DEVICE" \
-- add-port "$OVS_BRIDGE" "$DEVICE" $OVS_OPTIONS \
-- set Interface "$DEVICE" type=dpdk ${OVS_EXTRA+-- 
$OVS_EXTRA}
+   BRIDGE_MAC=$(get_hwaddr $OVS_BRIDGE)
+   # The bridge will change its MAC to be the lower one among all 
its
+   # ports. Restore the configuration if that happens.
+   if [ "$BRIDGE_MAC_ORIG" != "$BRIDGE_MAC" ]; then
+   OVSINTF=${DEVICE} /sbin/ifup "$OVS_BRIDGE"
+   fi
;;
OVSDPDKRPort)
ifup_ovs_bridge
@@ -196,12 +203,19 @@ case "$TYPE" in
;;
OVSDPDKBond)
ifup_ovs_bridge
+   BRIDGE_MAC_ORIG=$(get_hwaddr $OVS_BRIDGE)
for _iface in $BOND_IFACES; do
IFACE_TYPES="${IFACE_TYPES} -- set interface ${_iface} 
type=dpdk"
done
ovs-vsctl -t ${TIMEOUT} \
-- --if-exists del-port "$OVS_BRIDGE" "$DEVICE" \
-- add-bond "$OVS_BRIDGE" "$DEVICE" ${BOND_IFACES} 
$OVS_OPTIONS ${IFACE_TYPES} ${OVS_EXTRA+-- $OVS_EXTRA}
+   BRIDGE_MAC=$(get_hwaddr $OVS_BRIDGE)
+   # The bridge will change its MAC to be the lower one among all 
its
+   # ports. Restore the configuration if that happens.
+   if [ "$BRIDGE_MAC_ORIG" != "$BRIDGE_MAC" ]; then
+   OVSINTF=${DEVICE} /sbin/ifup "$OVS_BRIDGE"
+   fi
;;
*)
echo $"Invalid OVS interface type $TYPE"

-- 
Flavio

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

Re: [ovs-discuss] could not create netdev vhost-user1 of unknown type dpdkvhostuser

[Flavio Leitner]

On Thu, Dec 28, 2017 at 09:49:15PM +0800, 夏晨博 wrote:
> Hi,all
> 
> I tried to create vhost-user ports with OVS-DPDK, but failed. And I can't 
> find the solution.
> 
>  Step1: ovs-vsctl add-br br0 -- set bridge br0 datapath_type=netdev
>  Step2: ovs-vsctl add-port br0 vhost-user1 -- set Interface vhost-user1 
> type=dpdkvhostuser
> 
> Step 1 is ok. But Step2 failed. I checked the log, it says:
> 
> 2017-12-28T13:11:22.979Z|00020|netdev|WARN|could not create netdev 
> vhost-user1 of unknown type dpdkvhostuser
> 2017-12-28T13:11:22.979Z|00021|bridge|WARN|could not open network device 
> vhost-user1 (Address family not supported by protocol)
> 2017-12-28T13:11:59.036Z|00022|netdev|WARN|could not create netdev 
> vhost-user1 of unknown type dpdkvhostuser
> 2017-12-28T13:11:59.036Z|00023|bridge|WARN|could not open network device 
> vhost-user1 (Address family not supported by protocol)
> 2017-12-28T13:13:58.919Z|00024|netdev|WARN|could not create netdev 
> vhost-user1 of unknown type dpdkvhostuser
> 2017-12-28T13:13:58.919Z|00025|bridge|WARN|could not open network device 
> vhost-user1 (Address family not supported by protocol)
> 
> I wonder if anyone knows the reason.
> 
> OVS version: 2.8.1
> DPDK version: 17.05.1
> OS version: CentOS 7
> 
> I tried again in ubuntu using the openvswitch-switch-dpdk package, the same 
> problem happened.

You need to enable DPDK feature first.

-- 
Flavio


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

Re: [ovs-discuss] 回复： could not create netdev vhost-user1 of unknowntype dpdkvhostuser

[Flavio Leitner]

On Fri, Dec 29, 2017 at 10:16:51AM +0800, 夏晨博 wrote:
> Do you mean building OVS with '--with-dpdk' flag? Because I think I've done 
> that.

No, see:
https://github.com/openvswitch/ovs/blob/master/Documentation/intro/install/dpdk.rst#setup-ovs



> --
> Troy
> -- 原始邮件 --
> 发件人: "Flavio Leitner";<f...@sysclose.org>;
> 发送时间: 2017年12月29日(星期五) 凌晨2:14
> 收件人: "夏晨博"<524622...@qq.com>;
> 抄送: "ovs-discuss"<ovs-discuss@openvswitch.org>; 
> 主题: Re: [ovs-discuss] could not create netdev vhost-user1 of unknowntype 
> dpdkvhostuser
> 
> 
> 
> On Thu, Dec 28, 2017 at 09:49:15PM +0800, 夏晨博 wrote:
> > Hi,all
> > 
> > I tried to create vhost-user ports with OVS-DPDK, but failed. And I can't 
> > find the solution.
> > 
> >  Step1: ovs-vsctl add-br br0 -- set bridge br0 datapath_type=netdev
> >  Step2: ovs-vsctl add-port br0 vhost-user1 -- set Interface vhost-user1 
> > type=dpdkvhostuser
> > 
> > Step 1 is ok. But Step2 failed. I checked the log, it says:
> > 
> > 2017-12-28T13:11:22.979Z|00020|netdev|WARN|could not create netdev 
> > vhost-user1 of unknown type dpdkvhostuser
> > 2017-12-28T13:11:22.979Z|00021|bridge|WARN|could not open network device 
> > vhost-user1 (Address family not supported by protocol)
> > 2017-12-28T13:11:59.036Z|00022|netdev|WARN|could not create netdev 
> > vhost-user1 of unknown type dpdkvhostuser
> > 2017-12-28T13:11:59.036Z|00023|bridge|WARN|could not open network device 
> > vhost-user1 (Address family not supported by protocol)
> > 2017-12-28T13:13:58.919Z|00024|netdev|WARN|could not create netdev 
> > vhost-user1 of unknown type dpdkvhostuser
> > 2017-12-28T13:13:58.919Z|00025|bridge|WARN|could not open network device 
> > vhost-user1 (Address family not supported by protocol)
> > 
> > I wonder if anyone knows the reason.
> > 
> > OVS version: 2.8.1
> > DPDK version: 17.05.1
> > OS version: CentOS 7
> > 
> > I tried again in ubuntu using the openvswitch-switch-dpdk package, the same 
> > problem happened.
> 
> You need to enable DPDK feature first.
> 
> -- 
> Flavio

-- 
Flavio


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

Re: [ovs-discuss] getting build errors while building ovs2.7.0

[Flavio Leitner]

On Wed, Aug 29, 2018 at 11:10:38AM +0800, guoshaoch...@yunrongtech.com wrote:
> hello,
>  Has this problem been solved?
> If it is solved, can you tell me how to do it?
> thans very much!

Can you provide more details about the problem?
It builds fine over here.
-- 
Flavio

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

Re: [ovs-discuss] dpdk installation failed with OVS

[Flavio Leitner]

On Thu, Jul 12, 2018 at 05:02:02PM -0400, Sandeep Adapala wrote:
> I am having a HP ProLiant DL360 Gen9 (755258-B21) with Intel NIC
> 
> On Thu, Jul 12, 2018 at 3:43 PM, Ian Stokes  wrote:
> 
> > On 7/12/2018 8:28 PM, Sandeep Adapala wrote:
> >
> >> Yes that would be great help. Ben.
> >>
> >>
> > I've posted a patch to address this, comments are welcome.
> >
> > https://mail.openvswitch.org/pipermail/ovs-dev/2018-July/349611.html
> >
> > Ian, Flavio- Now I have moved little bit further. now I am in start
> >> switched step. I got this error when I do ovs-vswitchd unix:$DB_SOCK
> >> --pidfile --detach
> >>
> >> Device is ineligible for IOMMU domain attach due to platform RMRR
> >> requirement

Some platforms share RMRR regions with more devices and that breaks
isolation.  You need to contact your hardware vendor and check for
system BIOS updates or perhaps configuration guidance.

fbl



> >>
> >>
> > I haven't come across this error before myself, what type of platform are
> > you using?
> >
> > Ian
> >
> >>
> >> but my NIC is Intel05:00.0 Ethernet controller: Intel Corporation 82599ES
> >> 10-Gigabit SFI/SFP+ Network Connection (rev 01)
> >>
> >>
> >> So am I missing anything here?
> >>
> >>
> >> Regards,
> >>
> >> Sandeep
> >>
> >>
> >>
> >>
> >> On Thu, Jul 12, 2018 at 12:55 PM, Ben Pfaff  >> b...@ovn.org>> wrote:
> >>
> >> On Thu, Jul 12, 2018 at 03:42:08PM +0100, Ian Stokes wrote:
> >> > On 7/12/2018 3:26 PM, Flavio Leitner wrote:
> >> > >On Thu, Jul 12, 2018 at 09:41:24AM -0400, Sandeep Adapala wrote:
> >> > >>Hello Ian,
> >> > >>
> >> > >>Currently I am using Ubuntu 16.04 OS
> >> > >>OVS version is v2.6.1 and DPDK is v16.11.1
> >> > > I'd echo what Flavio has said below, also OVS 2.6.1 uses DPDK
> >> 16.07.1, I'm
> >> > not sure if it will work as is with DPDK 16.11. The OVS to DPDK
> >> version
> >> > mappings are available in the OVS release FAQ.
> >> > > http://docs.openvswitch.org/en/latest/faq/releases/
> >> <http://docs.openvswitch.org/en/latest/faq/releases/>
> >>
> >> Should we move that mapping in the DPDK installation instructions?
> >> Then
> >> we'd get fewer questions because users would have the right answer to
> >> that particular question whenever they read the instructions, even if
> >> they happened to read the instructions for the wrong version.
> >>
> >>
> >>
> >

-- 
Flavio

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

Re: [ovs-discuss] dpdk installation failed with OVS

[Flavio Leitner]

On Thu, Jul 12, 2018 at 09:41:24AM -0400, Sandeep Adapala wrote:
> Hello Ian,
> 
> Currently I am using Ubuntu 16.04 OS
> OVS version is v2.6.1 and DPDK is v16.11.1


You need to follow the instructions of the version you're using.
The doc url below refers to the latest OVS which is different than
the 2.6.1 you're using.

https://github.com/openvswitch/ovs/blob/branch-2.6/INSTALL.DPDK.md


> On Wed, Jul 11, 2018 at 1:40 PM, Ian Stokes  wrote:
> 
> > On 7/10/2018 10:30 PM, Sandeep Adapala wrote:
> >
> >> Hello,
> >>
> >> I am very new to OvS and DPDK but somehow after following the document
> >> http://docs.openvswitch.org/en/latest/intro/install/dpdk/ I went through
> >> till ovs service start step but the problem I get is when I run ovs-vsctl
> >> get Open_vSwitch . dpdk_initialized I don't get TRUE. I exactly did the
> >> same thing as mentioned in the doc but not sure why it is not running.

-- 
Flavio

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

Re: [ovs-discuss] Working of OVS

[Flavio Leitner]

On Fri, Jul 13, 2018 at 02:09:24PM +0530, karthik karra wrote:
> Hi,
> How come that the OVS is able to send and receive packets, even after
> installing on the wrong kernel ?

There are two options for the kernel side. The first is the module
that comes with the upstream kernel.  The second is the module that
is provided by openvswitch project.  I _guess_ you tried to install
openvswitch's module but it is still using the kernel's module?

It's not everyday I heard someone complaining that it works even though
it shouldn't. :-)

-- 
Flavio

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

Re: [ovs-discuss] REDHAT: Route issue with dpdk-bond ports

[Flavio Leitner]

On Thu, Jan 18, 2018 at 10:12:40AM +, Vishal Deep Ajmera wrote:
> > BTW, I suggested earlier but maybe I wasn't clear.
> > 
> > Instead of adding networking configuration to the bridge's port, just
> > leave it alone with a name that doesn't bother you.
> > 
> > Then create an internal port with the name and the networking
> > configuration you need. It won't change its MAC and neither lose
> > the routes. They both will be tap devices anyways.
> 
> Issue with assigning IP and routes to a tap port is that this tap port gets
> a random mac address which cannot be guaranteed to be unique
> across multiple nodes. I think that is the reason why bridge is assigned
> same mac address of a physical port (when port is added to a bridge) since 
> physical ports will have unique mac address.

You could use MACADDR= in ifcfg to have a stable MAC if that's only
issue, but yeah, you would have to manage them.

-- 
Flavio

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

Re: [ovs-discuss] REDHAT: Route issue with dpdk-bond ports

[Flavio Leitner]

On Thu, Jan 18, 2018 at 08:32:03AM +, Vishal Deep Ajmera wrote:
> > OK, what about this patch instead? It should fix the issue without the
> > errors.  I have not tested.
> 
> I tried your patch but it does not re-add the routes. The reason is doing
> $ ifup br0 will not invoke ifup-post since the bridge port is already UP and 
> so 
> $OVSBRIDGECONFIGURED will be 'true'.

Yes, yes, I forgot that when I looked at the DHCP scenario which will
not work in this case then.
> 
> I think instead of doing 'ifup $OVS_BRIDGE', we should run ${OTHERSCRIPT} 
> $OVS_BRIDGE 
> under the mac check. Tried this and it is working.

It looks good to me. I hope it does work for any number of ports
and doesn't show any errors.  If that's the case, please submit a
formal patch to ovs-dev@ and don't forget to request to patch 2.9
(if you need that) as it's branched off at this point.

Thanks for working on this!
fbl

> 
> Updated patch below.
> 
> + BRIDGE_MAC_ORIG=$(get_hwaddr $OVS_BRIDGE)
>   ovs-vsctl -t ${TIMEOUT} \
>   -- --if-exists del-port "$OVS_BRIDGE" "$DEVICE" \
>   -- add-port "$OVS_BRIDGE" "$DEVICE" $OVS_OPTIONS \
>   -- set Interface "$DEVICE" type=dpdk ${OVS_EXTRA+-- 
> $OVS_EXTRA}
> + BRIDGE_MAC=$(get_hwaddr $OVS_BRIDGE)
> + # The bridge will change its MAC to be the lower one among all 
> its
> + # ports. Restore the configuration if that happens.
> + if [ "$BRIDGE_MAC_ORIG" != "$BRIDGE_MAC" ]; then
> + ${OTHERSCRIPT} "$OVS_BRIDGE"
> + fi




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

Re: [ovs-discuss] Starting OVS w/ DPDK ...

[Flavio Leitner]

Hi,

On Mon, Oct 08, 2018 at 11:52:24AM +0200, Andrzej Ostruszka wrote:
> First of all thank you Flavio for your reply and sorry for late reply
> but I had to switch to something else.  Now I resume my ovs ramp up and
> have some additional problems.
> 
> My goal is actually to measure performance gain resulting from
> offloading of flow matching to HW.  I started with Marvell (even though
> it does not support at the moment RSS+MARK action in DPDK flow API)
> since I thought that if I get it up and running that would be a good
> starting point for adding support for flow matching offload to Marvell
> PMD.  However I do have problems even with what seems to be already
> supported.
> 
> For the moment I suspend the starting of OVS/DPDK on Marvell PMD and I'm
> trying to bring up the OVS with Mellanox MLX5 PMD.  That should be
> supported according to the documentation however I fail to bring it up.
> Maybe there is something very basic that I get wrong so I'd like to
> solicit some help to first start OVS/DPDK on this card (MCX516A-CDAT).
> Once I get this up and running I'll move to Marvell PMDs.
> 
> Let me shortly describe my attempt - maybe you'll spot something wrong.
> 1. I compile and install DPDK and test if testpmd has no problems
> (output at the end [1] in order to not clutter this e-mail too much).
> 
> 2. Then I configure ovs
> 
> ./configure --with-dpdk=$HOME/dpdk-install/usr/local
> --with-linux=/lib/modules/$(uname -r)/build LIBS="-libverbs -lmlx5"
> 
> and install it.
> 
> 3. I tell OVS to initialize DPDK
> 
> # ovs-vsctl get Open_vSwitch . other_config
> {dpdk-init="true"}
> 
> 4. I start it (without any bridge)
> 
> # ovs-ctl --delete-bridges start
> 
>  * Starting ovsdb-server
>  * system ID not configured, please use --system-id
>  * Configuring Open vSwitch system IDs
> Zone 0: name:, IO:0x5e9b6000, len:0x34900,
> virt:0x7f8dd29b6000, socket_id:0, flags:0
>  * Starting ovs-vswitchd
>  * Enabling remote OVSDB managers
> 
> 5. Then I attach to ovs-vswitchd in gdb and set breakpoint in
> rte_eal_hotplug_add
> 
> 6. Then I add bridge and first DPDK port
> 
> # ovs-vsctl add-br br0 -- set bridge br0 datapath_type=netdev
> # ovs-vsctl add-port br0 dpdk-p0 -- set Interface dpdk-p0 type=dpdk
>   options:dpdk-devargs=08:00.0
> 
> 7. In the debugger I step through until I get to pci_find_device() and
> in there the comparison function used is 'cmp_detached_dev_name()' which
> checks for dev->drive to be NULL and in my case it is not as it points
> to mlx5 driver:
> 
> (gdb) p name
> $23 = 0x262c250 "08:00.0"
> (gdb) p *dev
> $24 = {next = {tqe_next = 0x0, tqe_prev = 0x0}, name = 0x25fa5c0 "08:00.0",
>   driver = 0xc96b30 , numa_node = 0, devargs = 0x25fa5a0}
> (gdb) n
> 55  return 1;
> 
> and as a result it fails to add port:
> 
> ovs-vsctl: Error detected while setting up 'dpdk-p0': Error attaching
> device '08:00.0' to DPDK.  See ovs-vswitchd log for details.
> ovs-vsctl: The default log directory is "/usr/local/var/log/openvswitch".
> 
> and in there the confirmation from DPDK:
> 
> 2018-10-08T09:38:28.234Z|00058|dpdk|ERR|EAL: Cannot find unplugged
> device (08:00.0)
> 2018-10-08T09:38:28.234Z|00059|netdev_dpdk|WARN|Error attaching device
> '08:00.0' to DPDK
> 2018-10-08T09:38:28.234Z|00060|netdev|WARN|dpdk-p0: could not set
> configuration (Invalid argument)
> 
> So basically port seems to be attached (to correct driver) but somehow
> detached port is searched for.  Seems very much like some config problem
> but I don't know OVS enough to figure it out.
> 
> So I'd still appreciate some help in bringing OVS w/ DPDK up.

I've not tried Mellanox myself in a while now, but I found a piece of
documentation that you might have missed:

Documentation/howto/dpdk.rst:
[...]
Some NICs (i.e. Mellanox ConnectX-3) have only one PCI address associated with
multiple ports. Using a PCI device like above won't work. Instead, below usage
is suggested::   
 
$ ovs-vsctl add-port br0 dpdk-p0 -- set Interface dpdk-p0
type=dpdk \
options:dpdk-devargs="class=eth,mac=00:11:22:33:44:55"
$ ovs-vsctl add-port br0 dpdk-p1 -- set Interface dpdk-p1
type=dpdk \
options:dpdk-devargs="class=eth,mac=00:11:22:33:44:56"
[...]


> > BTW the bridge 'br0' also needs to be in the userspace DP.
> 
> Ohh, that seems to be in contrast to what this doc:
> http://docs.openvswitch.org/en/latest/howto/dpdk/
> seems to suggest.  It tells that the bridge has to be netdev (or maybe I
> don't understand what the 'netdev' datapath type is).

That is correct.

-- 
Flavio

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

Re: [ovs-discuss] time for another LTS?

[Flavio Leitner]

On Fri, Oct 19, 2018 at 08:23:37AM -0700, Ben Pfaff wrote:
> On Fri, Oct 19, 2018 at 11:48:07AM +, Stokes, Ian wrote:
> > > On 10/18/2018 10:46 PM, Ben Pfaff wrote:
> > > > I've had a number of queries from folks lately about our roadmap for
> > > > LTS releases.  It has, indeed, been a long time since we've had a
> > > > long-term support release (the current LTS is 2.5).  Usually, we've
> > > > done LTS releases before some kind of big architectural change, etc.,
> > > > and so we've had no real internal pressure within the project to do it
> > > > for a while.  But it might be a good signal to the community to bring
> > > > the LTS release forward.
> > > >
> > > > What does everyone think about making the next (2.11) release an LTS?
> > > >
> > > 
> > > I think it's a good idea. The current LTS is quite old now, especially for
> > > the DPDK datapath. There is a new DPDK LTS coming out in November which
> > > should be in for OVS 2.11, so it would be a nice combination for a user to
> > > have LTS support for both.
> > 
> > +1
> > 
> > With regards backporting support for LTS releases, I take it LTS takes 
> > priority over non LTS branches, that would be the only difference I would 
> > think?
> 
> Yes, basically we should try harder to backport to LTS branches.
> 
> > In fairness I think the community is pretty good as is for backporting
> > bug fixes for all branches.
> 
> We do a pretty good job of it most of the time.  The main driver for LTS
> releases has been big OVS internal changes that are likely to break
> things.  By doing an LTS release just before a version with those kinds
> of changes, we gave our users something to confidently fall back on if
> the next release was a little more unstable--not that we ever aim for
> that, but it happens sometimes.  We haven't had that kind of big change
> recently, so we haven't had a natural impetus to release an LTS--and for
> the same reason, it's been easy to backport most fixes because there
> haven't been sweeping changes across the tree.

What comes to mind is if OVN manages to split up from OVS soon.
Wouldn't be easier if OVN, as a separated project, requires
an OVS LTS version? If so, then 2.11 might not be the best one.

-- 
Flavio

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

Re: [ovs-discuss] OVS local port overloaded

[Flavio Leitner]

On Tue, Oct 30, 2018 at 10:29:37AM +0700, Soe Ye Htet wrote:
> Dear OvS Team,
> 
> I have one problem in openvswitch. Let me state my simple tested toplogy.
> OVS1(RYU)---OVS2. Instead of applying ovs inband mode, I configure my
> own predefiend fules in OvS1 & 2 to apply in band scemario according to my
> work. RYU controller can connect successfully to OvS1 and 2. Then Iperf3
> connection has been established between OvS1 and OvS2. OvS1 is a server and
> OvS2 is a receiver. After sometime, Iperf3 connection is broken and the
> local port ftom OVS2 cannot transmit packet.

See if there is any relevant message in the ovs-vswitchd.log or
journal.

-- 
Flavio

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

Re: [ovs-discuss] Starting OVS w/ DPDK ...

[Flavio Leitner]

On Tue, Oct 23, 2018 at 11:53:30AM +0200, Andrzej Ostruszka wrote:
> Flavio
> 
> Thank you again for trying to help me.  Luckily I've solved the problem.
>  So here I'll just document it for the benefit of other people with the
> same problem.

Hi Andrzej,

Glad to know that you solved the problem. I am not sure if you're
familiar with git and patch. If you are, perhaps this would be a
great opportunity for you to change the relevant documentation to
add your findings and send us a patch.

If you're not comfortable in doing it, I'd suggest to send a 
documentation snippet, then we can try to integrate it.

Thanks,
fbl

> 
> On 10/19/2018 08:12 PM, Flavio Leitner wrote:
> > On Mon, Oct 08, 2018 at 11:52:24AM +0200, Andrzej Ostruszka wrote:
> [...]
> >> ovs-vsctl: Error detected while setting up 'dpdk-p0': Error attaching
> >> device '08:00.0' to DPDK.  See ovs-vswitchd log for details.
> >> ovs-vsctl: The default log directory is "/usr/local/var/log/openvswitch".
> >>
> >> and in there the confirmation from DPDK:
> >>
> >> 2018-10-08T09:38:28.234Z|00058|dpdk|ERR|EAL: Cannot find unplugged
> >> device (08:00.0)
> >> 2018-10-08T09:38:28.234Z|00059|netdev_dpdk|WARN|Error attaching device
> >> '08:00.0' to DPDK
> >> 2018-10-08T09:38:28.234Z|00060|netdev|WARN|dpdk-p0: could not set
> >> configuration (Invalid argument)
> 
> The key word in the above log was "unplugged".  What actually happened
> when I have given PCI address is that OvS tried to attach the driver
> when it already has been attached.
> 
> So it looks like upon the startup OvS does a scan and attaches the ports
> (excerpt from the log):
> |INFO|EAL: PCI device :01:00.0 on NUMA socket -1
> |WARN|EAL:   Invalid NUMA socket, default to 0
> |INFO|EAL:   probe driver: 15b3:1019 net_mlx5
> |INFO|PMD: net_mlx5: PCI information matches, using device "mlx5_0"
> (SR-IOV: false)
> |INFO|PMD: net_mlx5: 1 port(s) detected
> 
> So I've taken a look at the code and saw that OvS takes the dpdk-devargs
> and first searches for the port by that name and if not found then it
> tries to attach/hotplug using this value.  Thus the solution was to
> change the value of dpdk-devargs to the name of the port (mlx5_0 and
> mlx5_1) instead of PCI address.  So with the following config everything
> works just fine - I guess the documentation could be updated a bit though.
> 
> # ovs-vsctl show
> 67be421b-d397-4173-b1d5-e7d80f641daa
> Bridge "br0"
> Port "dpdk-p1"
> Interface "dpdk-p1"
> type: dpdk
> options: {dpdk-devargs="mlx5_1"}
> Port "br0"
> Interface "br0"
> type: internal
> Port "dpdk-p0"
> Interface "dpdk-p0"
> type: dpdk
> options: {dpdk-devargs="mlx5_0"}
> ovs_version: "2.10.90"
> 
> Best regards
> Andrzej
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

-- 
Flavio

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

Re: [ovs-discuss] Issue when using local_ip with VXLAN tunnels in OVS

[Flavio Leitner]

On Tue, Nov 06, 2018 at 11:51:49AM -0500, Siva Teja ARETI wrote:
> Hi Greg,
> 
> Thanks for looking into this.
> 
> I have two VMs in my setup each with two interfaces. Trying to setup the
> VXLAN tunnels across these interfaces which are in different subnets. A
> docker container is attached to ovs bridge using ovs-docker utility on each
> VM and doing a ping from one container to another.

Do you see any interesting related messages in 'dmesg' output or in 
ovs-vswitchd.log?

If I recall correctly, the "ip l" should show the vxlan dev named
vxlan_sys_.

fbl

> 
> *VM1 details:*
> 
> [root@vm1 ~]# ip a
> ...
> 3: eth1:  mtu 1500 qdisc pfifo_fast state
> UP qlen 1000
> link/ether 52:54:00:b8:05:be brd ff:ff:ff:ff:ff:ff
> inet 30.30.0.59/24 brd 30.30.0.255 scope global dynamic eth1
>valid_lft 3002sec preferred_lft 3002sec
> inet6 fe80::5054:ff:feb8:5be/64 scope link
>valid_lft forever preferred_lft forever
> 4: eth2:  mtu 1500 qdisc pfifo_fast state
> UP qlen 1000
> link/ether 52:54:00:f0:64:37 brd ff:ff:ff:ff:ff:ff
> inet 20.20.0.183/24 brd 20.20.0.255 scope global dynamic eth2
>valid_lft 3248sec preferred_lft 3248sec
> inet6 fe80::5054:ff:fef0:6437/64 scope link
>valid_lft forever preferred_lft forever
> ...
> [root@vm1 ~]# ovs-vsctl show
> ff70c814-d1b0-4018-aee8-8b635187afee
> Bridge "testbr0"
> Port "gre0"
> Interface "gre0"
> type: gre
> options: {local_ip="20.20.0.183", remote_ip="30.30.0.193"}
> Port "testbr0"
> Interface "testbr0"
> type: internal
> Port "2cfb62a9b0f04_l"
> Interface "2cfb62a9b0f04_l"
> ovs_version: "2.9.2"
> [root@vm1 ~]# ip rule list
> 0:  from all lookup local
> 32765:  from 20.20.0.183 lookup siva
> 32766:  from all lookup main
> 32767:  from all lookup default
> [root@vm1 ~]# ip route show table siva
> default dev eth2 scope link src 20.20.0.183
> [root@vm1 ~]# # A docker container is attached to
> ovs bridge using ovs-docker utility
> [root@vm1 ~]# docker ps
> CONTAINER IDIMAGE   COMMAND CREATED
>  STATUS  PORTS   NAMES
> be4ab434db99busybox "sh"5 days ago
> Up 5 days   admiring_euclid
> [root@vm1 ~]# nsenter -n -t `docker inspect be4 --format={{.State.Pid}}` --
> ip a
> 1: lo:  mtu 65536 qdisc noqueue state UNKNOWN qlen 1
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
>valid_lft forever preferred_lft forever
> inet6 ::1/128 scope host
>valid_lft forever preferred_lft forever
> 2: gre0@NONE:  mtu 1476 qdisc noop state DOWN qlen 1
> link/gre 0.0.0.0 brd 0.0.0.0
> 3: gretap0@NONE:  mtu 1462 qdisc noop state DOWN qlen
> 1000
> link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
> 9: eth0@if10:  mtu 1500 qdisc noqueue
> state UP qlen 1000
> link/ether 22:98:41:0f:e8:50 brd ff:ff:ff:ff:ff:ff link-netnsid 0
> inet 70.70.0.10/24 scope global eth0
>valid_lft forever preferred_lft forever
> inet6 fe80::2098:41ff:fe0f:e850/64 scope link
>valid_lft forever preferred_lft forever
> 
> 
> *VM2 details:*
> 
> [root@vm2 ~]# ip a
> 
> 3: eth1:  mtu 1500 qdisc pfifo_fast state
> UP qlen 1000
> link/ether 52:54:00:79:ef:92 brd ff:ff:ff:ff:ff:ff
> inet 30.30.0.193/24 brd 30.30.0.255 scope global dynamic eth1
>valid_lft 2406sec preferred_lft 2406sec
> inet6 fe80::5054:ff:fe79:ef92/64 scope link
>valid_lft forever preferred_lft forever
> 4: eth2:  mtu 1500 qdisc pfifo_fast state
> UP qlen 1000
> link/ether 52:54:00:05:93:7c brd ff:ff:ff:ff:ff:ff
> inet 20.20.0.64/24 brd 20.20.0.255 scope global dynamic eth2
>valid_lft 2775sec preferred_lft 2775sec
> inet6 fe80::5054:ff:fe05:937c/64 scope link
>valid_lft forever preferred_lft forever
> ...
> [root@vm2 ~]# ovs-vsctl show
> b85514db-3f29-4f7a-9001-37d70adfca34
> Bridge "testbr0"
> Port "gre0"
> Interface "gre0"
> type: gre
> options: {local_ip="30.30.0.193", remote_ip="20.20.0.183"}
> Port "a0769422cfc04_l"
> Interface "a0769422cfc04_l"
> Port "testbr0"
> Interface "testbr0"
> type: internal
> ovs_version: "2.9.2"
> [root@vm2 ~]# ip rule list
> 0:  from all lookup local
> 32766:  from all lookup main
> 32767:  from all lookup default
> [root@vm2 ~]# # A docker container is attached to
> ovs bridge using ovs-docker utility
> [root@vm2 ~]# docker ps
> CONTAINER IDIMAGE   COMMAND CREATED
>  STATUS  PORTS   NAMES
> 86214f0d99e8busybox:latest  "sh"5 days ago
> Up 5 days   peaceful_snyder
> 

Re: [ovs-discuss] Issue when using local_ip with VXLAN tunnels in OVS

[Flavio Leitner]

On Tue, Nov 06, 2018 at 02:09:23PM -0500, Siva Teja ARETI wrote:
> Answers in line.
> 
> Siva Teja.
> 
> On Tue, Nov 6, 2018 at 1:56 PM Flavio Leitner  wrote:
> 
> > On Tue, Nov 06, 2018 at 11:51:49AM -0500, Siva Teja ARETI wrote:
> > > Hi Greg,
> > >
> > > Thanks for looking into this.
> > >
> > > I have two VMs in my setup each with two interfaces. Trying to setup the
> > > VXLAN tunnels across these interfaces which are in different subnets. A
> > > docker container is attached to ovs bridge using ovs-docker utility on
> > each
> > > VM and doing a ping from one container to another.
> >
> > Do you see any interesting related messages in 'dmesg' output or in
> > ovs-vswitchd.log?
> >
> 
> I could not find any interesting messages in dmesg or in ovs-vswitchd.log
> output.
> 
> 
> > If I recall correctly, the "ip l" should show the vxlan dev named
> > vxlan_sys_
> >
> 
> Yes. I can see the dev on both of my VMs
> 
> [root@vm1 ~]# ifconfig vxlan_sys_4789
> vxlan_sys_4789: flags=4163  mtu 65000
> inet6 fe80::2a:28ff:fed2:d4f6  prefixlen 64  scopeid 0x20
> ether 02:2a:28:d2:d4:f6  txqueuelen 1000  (Ethernet)
> RX packets 0  bytes 0 (0.0 B)
> RX errors 0  dropped 0  overruns 0  frame 0
> TX packets 48  bytes 1680 (1.6 KiB)
> TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Do you see TX increasing as you execute the test?
or in ovs-ofctl dump-ports  ?

Thanks,
fbl

> 
> 
> 
> > fbl
> >
> > >
> > > *VM1 details:*
> > >
> > > [root@vm1 ~]# ip a
> > > ...
> > > 3: eth1:  mtu 1500 qdisc pfifo_fast
> > state
> > > UP qlen 1000
> > > link/ether 52:54:00:b8:05:be brd ff:ff:ff:ff:ff:ff
> > > inet 30.30.0.59/24 brd 30.30.0.255 scope global dynamic eth1
> > >valid_lft 3002sec preferred_lft 3002sec
> > > inet6 fe80::5054:ff:feb8:5be/64 scope link
> > >valid_lft forever preferred_lft forever
> > > 4: eth2:  mtu 1500 qdisc pfifo_fast
> > state
> > > UP qlen 1000
> > > link/ether 52:54:00:f0:64:37 brd ff:ff:ff:ff:ff:ff
> > > inet 20.20.0.183/24 brd 20.20.0.255 scope global dynamic eth2
> > >valid_lft 3248sec preferred_lft 3248sec
> > > inet6 fe80::5054:ff:fef0:6437/64 scope link
> > >valid_lft forever preferred_lft forever
> > > ...
> > > [root@vm1 ~]# ovs-vsctl show
> > > ff70c814-d1b0-4018-aee8-8b635187afee
> > > Bridge "testbr0"
> > > Port "gre0"
> > > Interface "gre0"
> > > type: gre
> > > options: {local_ip="20.20.0.183",
> > remote_ip="30.30.0.193"}
> > > Port "testbr0"
> > > Interface "testbr0"
> > > type: internal
> > > Port "2cfb62a9b0f04_l"
> > > Interface "2cfb62a9b0f04_l"
> > > ovs_version: "2.9.2"
> > > [root@vm1 ~]# ip rule list
> > > 0:  from all lookup local
> > > 32765:  from 20.20.0.183 lookup siva
> > > 32766:  from all lookup main
> > > 32767:  from all lookup default
> > > [root@vm1 ~]# ip route show table siva
> > > default dev eth2 scope link src 20.20.0.183
> > > [root@vm1 ~]# # A docker container is attached
> > to
> > > ovs bridge using ovs-docker utility
> > > [root@vm1 ~]# docker ps
> > > CONTAINER IDIMAGE   COMMAND CREATED
> > >  STATUS  PORTS   NAMES
> > > be4ab434db99busybox "sh"5 days ago
> > > Up 5 days   admiring_euclid
> > > [root@vm1 ~]# nsenter -n -t `docker inspect be4
> > --format={{.State.Pid}}` --
> > > ip a
> > > 1: lo:  mtu 65536 qdisc noqueue state UNKNOWN qlen
> > 1
> > > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> > > inet 127.0.0.1/8 scope host lo
> > >valid_lft forever preferred_lft forever
> > > inet6 ::1/128 scope host
> > >valid_lft forever preferred_lft forever
> > > 2: gre0@NONE:  mtu 1476 qdisc noop state DOWN qlen 1
> > > link/gre 0.0.0.0 brd 0.0.0.0
> > > 3: gretap0@NONE:  mtu 1462 qdisc noop state DOWN
> > qlen
> > > 1000
> > > lin

Re: [ovs-discuss] Issue when using local_ip with VXLAN tunnels in OVS

[Flavio Leitner]

On Tue, Nov 06, 2018 at 06:21:22PM -0500, Siva Teja ARETI wrote:
> Yes. Packet counts are incremented.
> 
> [root@vm1 ~]# ovs-ofctl dump-ports testbr0
> OFPST_PORT reply (xid=0x2): 3 ports
>   port LOCAL: rx pkts=0, bytes=0, drop=68726, errs=0, frame=0, over=0, crc=0
>tx pkts=0, bytes=0, drop=0, errs=0, coll=0
>   port  vxlan0: rx pkts=0, bytes=0, drop=?, errs=?, frame=?, over=?, crc=?
>tx pkts=58, bytes=2436, drop=?, errs=?, coll=?
>   port  "2cfb62a9b0f04_l": rx pkts=69211, bytes=2918374, drop=0, errs=0,
> frame=0, over=0, crc=0
>tx pkts=190, bytes=17532, drop=0, errs=0, coll=0


It sounds like you have a MTU issue. When using VXLAN, the packet is
not passing somewhere.

fbl


> 
> Siva Teja.
> 
> On Tue, Nov 6, 2018 at 6:15 PM Flavio Leitner  wrote:
> 
> > On Tue, Nov 06, 2018 at 02:09:23PM -0500, Siva Teja ARETI wrote:
> > > Answers in line.
> > >
> > > Siva Teja.
> > >
> > > On Tue, Nov 6, 2018 at 1:56 PM Flavio Leitner  wrote:
> > >
> > > > On Tue, Nov 06, 2018 at 11:51:49AM -0500, Siva Teja ARETI wrote:
> > > > > Hi Greg,
> > > > >
> > > > > Thanks for looking into this.
> > > > >
> > > > > I have two VMs in my setup each with two interfaces. Trying to setup
> > the
> > > > > VXLAN tunnels across these interfaces which are in different
> > subnets. A
> > > > > docker container is attached to ovs bridge using ovs-docker utility
> > on
> > > > each
> > > > > VM and doing a ping from one container to another.
> > > >
> > > > Do you see any interesting related messages in 'dmesg' output or in
> > > > ovs-vswitchd.log?
> > > >
> > >
> > > I could not find any interesting messages in dmesg or in ovs-vswitchd.log
> > > output.
> > >
> > >
> > > > If I recall correctly, the "ip l" should show the vxlan dev named
> > > > vxlan_sys_
> > > >
> > >
> > > Yes. I can see the dev on both of my VMs
> > >
> > > [root@vm1 ~]# ifconfig vxlan_sys_4789
> > > vxlan_sys_4789: flags=4163  mtu 65000
> > > inet6 fe80::2a:28ff:fed2:d4f6  prefixlen 64  scopeid 0x20
> > > ether 02:2a:28:d2:d4:f6  txqueuelen 1000  (Ethernet)
> > > RX packets 0  bytes 0 (0.0 B)
> > > RX errors 0  dropped 0  overruns 0  frame 0
> > > TX packets 48  bytes 1680 (1.6 KiB)
> > > TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
> >
> > Do you see TX increasing as you execute the test?
> > or in ovs-ofctl dump-ports  ?
> >
> > Thanks,
> > fbl
> >
> > >
> > >
> > >
> > > > fbl
> > > >
> > > > >
> > > > > *VM1 details:*
> > > > >
> > > > > [root@vm1 ~]# ip a
> > > > > ...
> > > > > 3: eth1:  mtu 1500 qdisc pfifo_fast
> > > > state
> > > > > UP qlen 1000
> > > > > link/ether 52:54:00:b8:05:be brd ff:ff:ff:ff:ff:ff
> > > > > inet 30.30.0.59/24 brd 30.30.0.255 scope global dynamic eth1
> > > > >valid_lft 3002sec preferred_lft 3002sec
> > > > > inet6 fe80::5054:ff:feb8:5be/64 scope link
> > > > >valid_lft forever preferred_lft forever
> > > > > 4: eth2:  mtu 1500 qdisc pfifo_fast
> > > > state
> > > > > UP qlen 1000
> > > > > link/ether 52:54:00:f0:64:37 brd ff:ff:ff:ff:ff:ff
> > > > > inet 20.20.0.183/24 brd 20.20.0.255 scope global dynamic eth2
> > > > >valid_lft 3248sec preferred_lft 3248sec
> > > > > inet6 fe80::5054:ff:fef0:6437/64 scope link
> > > > >valid_lft forever preferred_lft forever
> > > > > ...
> > > > > [root@vm1 ~]# ovs-vsctl show
> > > > > ff70c814-d1b0-4018-aee8-8b635187afee
> > > > > Bridge "testbr0"
> > > > > Port "gre0"
> > > > > Interface "gre0"
> > > > > type: gre
> > > > > options: {local_ip="20.20.0.183",
> > > > remote_ip="30.30.0.193"}
> > > > > Port "testbr0"
> > > > > Interface "testbr0"
> > > > > type: internal
> > > > > 

Re: [ovs-discuss] Multicast snooping turned off on interfaces with a multicast querier/router

[Flavio Leitner]

On Thu, Aug 30, 2018 at 04:35:40PM -0700, Ben Pfaff wrote:
> This test was part of the original commit by Flavio.
> 
> Flavio, do you have any information?

Hi,

> On Thu, Aug 30, 2018 at 03:17:04PM -0700, Ajit Warrier wrote:
> > I confirmed from the source code that it is intentional. The snooping is
> > disabled on ports with routers attached in:
> > 
> > lib/mcast-snooping.c:mcast_snooping_add_group()
> > 
> > 
> > /* Avoid duplicate packets. */
> > if (mcast_snooping_mrouter_lookup(ms, vlan, port)
> > || mcast_snooping_port_lookup(>fport_list, port)) {
> > return false;
> > }
> > 
> > It would be nice to know why this is so.

It's been a while, but IIRC it tracks three situations: ports with flood
enabled, ports with mcast router attached and ports with mcast clients.
There is a list for each situation.

You most probably see the mcast router in the mdb/show, but yeah, it
doesn't mix the types because then you would see the same packet being
forwarded because of the mcast router and another copy because of the
mcast host client.

I recall that there was a restriction when sending reports, but I
suspect we could fix the code to allow mcast hosts and routers in
the same port.

Could you tell more about your requirements?
Thanks
fbl

> > Thanks,
> > Ajit.
> > 
> > On Thu, 30 Aug 2018 at 14:06 Ben Pfaff  wrote:
> > 
> > > On Tue, Aug 28, 2018 at 01:05:42PM -0700, Ajit Warrier wrote:
> > > > I have a setup where an embedded device runs OVS on a bridge connecting
> > > two
> > > > interfaces (1 and 2). Interface 1 is connected to a multicast router
> > > > sending IGMP queries periodically. Now if I open a multicast socket on a
> > > > device on interface 1, I see the IGMP join going into the embedded 
> > > > device
> > > > with OVS, but the command:
> > > >
> > > > ovs-appctl mdb/show br0
> > > >
> > > > does not list that multicast flow. Opening a multicast socket on a 
> > > > device
> > > > connected to interface 2 works as expected - I get an entry for that 
> > > > flow
> > > > in the above command.
> > >
> > > We've had a multicast snooping fixes over time.  If you're not using the
> > > latest release, please consider upgrading.
> > >
> 
> > ___
> > 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

-- 
Flavio

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

Re: [ovs-discuss] vswitchd 2.9.3/2.10.1 crashes handling port add/mod

[Flavio Leitner]

On Wed, Dec 05, 2018 at 12:11:28PM +1300, Josh Bailey via discuss wrote:
> Hello OVS colleagues,
> 
> vswitchd appears to crash handling a port add/mod. Please see following to
> reproduce.
> 
> Run two Ryu OF controllers:
> 
> $ ryu-manager --ofp-tcp-listen-port 6653  --ofp-listen-host 127.0.0.1
> --verbose --app-lists ryu.app.simple_switch_stp
> 
> $ ryu-manager --ofp-tcp-listen-port 6654  --ofp-listen-host 127.0.0.1
> --verbose --app-lists ryu.app.simple_switch_stp
> 
> 
> Now set up a bridge with no interfaces:
> 
> 
> root@faucet:~/faucet# /usr/local/share/openvswitch/scripts/ovs-ctl start
> * Starting ovsdb-server
> * system ID not configured, please use --system-id
> * Configuring Open vSwitch system IDs
> * Starting ovs-vswitchd
> * Enabling remote OVSDB managers
> root@faucet:~/faucet# ovs-vsctl --version
> ovs-vsctl (Open vSwitch) 2.9.3
> DB Schema 7.15.1
> root@faucet:~/faucet# ovs-vsctl add-br br0
> root@faucet:~/faucet# ovs-vsctl set-controller br0 tcp:127.0.0.1:6653 tcp:
> 127.0.0.1:6654
> 
> 
> Now add a physical interface known to be up:
> 
> 
> root@faucet:~/faucet# ovs-vsctl add-port br0 enp2s0f0
> 
> 
> Observe crash in log:
> 
> 
> 2018-12-04T23:03:06.663Z|00036|bridge|INFO|bridge br0: added interface
> enp2s0f0 on port 1
> 2018-12-04T23:03:06.663Z|00037|bridge|INFO|bridge br0: using datapath ID
> 90e2ba7e7558
> 2018-12-04T23:03:06.663Z|00038|rconn|INFO|br0<->tcp:127.0.0.1:6653:
> disconnecting
> 2018-12-04T23:03:06.663Z|00039|rconn|INFO|br0<->tcp:127.0.0.1:6654:
> disconnecting
> 2018-12-04T23:03:06.664Z|00040|fail_open|WARN|Could not connect to
> controller (or switch failed controller's post-connection admission control
> policy) for 19 seconds, failing open
> 2018-12-04T23:03:06.710Z|2|daemon_unix(monitor)|ERR|1 crashes: pid 5620
> died, killed (Aborted), core dumped, restarting

Please open the coredump using gdb and provide the backtrace at least,
Thanks,
-- 
fbl

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

Re: [ovs-discuss] actions=in_port behavior

[Flavio Leitner]

On Fri, Dec 07, 2018 at 12:24:02PM +, Sachin Sharma wrote:
> Hi all,
> I have created a setup of two nodes : VMa-VMb. I ran ovs in VMb and
> added the following flow entry in vmb:  ovs-ofctl add-flow vmb in_port=1,
> actions=in_port.
> I now sent a ping message from VMa towards VMb.  As I have a flow entry at
> VMb with actions= in_port, I expect that the same packet should be received
> by VMa. However, this is not happening.
> 
> Currently, packets are looping back at VMb without even going to VMa
> (similar to hair pin). Is this the correct behavior of the above flow
> entry? or should VMa receive the packet which it has sent it before to VMb?

What do you mean by 'looping back at VMb?' 

actions=in_port is a special output syntax where you tell OVS that it
should send the packet on the ingress port.

Check the flow stats - ovs-ofctl dump-flows ovsbr0 
and see if the rule is being used while you run the test.

-- 
Flavio

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

Re: [ovs-discuss] Cannot Bind eth0 to Driver vfio-pci

[Flavio Leitner]

On Wed, Dec 05, 2018 at 08:01:45PM +0530, Numan Siddique wrote:
> On Wed, Dec 5, 2018 at 4:27 PM Ramzah Rehman  wrote:
> 
> > I am trying to bind an interface eth0 to vfio driver. I have made sure
> > iommu is enabled in grub and kernel. I have loaded the module vfio-pci. Ran
> > following commands
> >
> > #modprobe vfio-pci
> > #chmod a+x /dev/vfio
> > #chmod 0666 /dev/vfio/*
> > #export DPDK_DIR=/usr/src/dpdk-stable-17.11.4
> > #sudo $DPDK_DIR/usertools/dpdk-devbind.py --bind=vfio-pci 02:01.0
> >
> > I got following error:
> >
> > Error: bind failed for :02:01.0 - Cannot bind to driver vfio-pci
> >
> > I checked the error in dmesg:
> >
> > Got :
> >
> > [ 1815.793823] vfio-pci: probe of :02:01.0 failed with error -22
> >
> > let me know the reason.
> >
> >
> Maybe posting this to dpdk mailing list could get you some answer.

You need to enable iommu in the kernel passing 2~3 parameters to
the kernel cmdline and also make sure that the device is okay inside
a iommu group (not sharing with other devices).

-- 
Flavio

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

Re: [ovs-discuss] actions=in_port behavior

[Flavio Leitner]

On Mon, Dec 10, 2018 at 07:20:03PM +, Sachin Sharma wrote:
> Hi Flavio,
> 
> Thanks for your reply!
> The packet counter in the flow-stats (using dump-flows) is  increasing very
> rapidly.
> I have just sent 1 packet. If I dump traffic through tcpdump, there are
> lots of packets appearing. I think that the same packet is looping back.

Oh, sounds like you have a network loop.
Can't help more without knowing all the relevant connection details.
fbl


> 
> Kind Regards,
> Sachin.
> 
> On Mon, Dec 10, 2018 at 7:01 PM Flavio Leitner  wrote:
> 
> > On Fri, Dec 07, 2018 at 12:24:02PM +, Sachin Sharma wrote:
> > > Hi all,
> > > I have created a setup of two nodes : VMa-VMb. I ran ovs in VMb and
> > > added the following flow entry in vmb:  ovs-ofctl add-flow vmb in_port=1,
> > > actions=in_port.
> > > I now sent a ping message from VMa towards VMb.  As I have a flow entry
> > at
> > > VMb with actions= in_port, I expect that the same packet should be
> > received
> > > by VMa. However, this is not happening.
> > >
> > > Currently, packets are looping back at VMb without even going to VMa
> > > (similar to hair pin). Is this the correct behavior of the above flow
> > > entry? or should VMa receive the packet which it has sent it before to
> > VMb?
> >
> > What do you mean by 'looping back at VMb?'
> >
> > actions=in_port is a special output syntax where you tell OVS that it
> > should send the packet on the ingress port.
> >
> > Check the flow stats - ovs-ofctl dump-flows ovsbr0
> > and see if the rule is being used while you run the test.
> >
> > --
> > Flavio
> >
> >

-- 
Flavio

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

Re: [ovs-discuss] vswitchd 2.9.3/2.10.1 crashes handling port add/mod

[Flavio Leitner]

Looks like you're using an unsupported OpenFlow protocol:
https://github.com/openvswitch/ovs/blob/5f361a2a320717c46289fc30d65a186f2f5d3ba0/lib/ofp-protocol.c#L123

I see that you are configuring a controller in OVS and you are
running Ryu, maybe it's using the wrong protocol version?

fbl

On Tue, Dec 11, 2018 at 08:07:51AM +1300, Josh Bailey wrote:
> Certainly:
> 
> 2018-12-04 21:23:59 josh #1  0x7f870edf9801 in __GI_abort () at
> abort.c:79
> 
> 2018-12-04 21:23:59 josh #2  0x5634f368e0a8 in
> ofputil_protocol_to_ofp_version (protocol=) at
> lib/ofp-protocol.c:123
> 
> 2018-12-04 21:23:59 josh #3  0x5634f36890ae in
> ofputil_encode_port_status (ps=ps@entry=0x7ffef1dc7880, protocol= out>) at lib/ofp-port.c:938
> 
> 2018-12-04 21:23:59 josh #4  0x5634f35f7ab2 in connmgr_send_port_status
> (mgr=0x5634f518a9a0, source=source@entry=0x0, pp=pp@entry=0x5634f5247310,
> reason=reason@entry=2 '\002') at ofproto/connmgr.c:1654
> 
> 2018-12-04 21:23:59 josh #5  0x5634f35bcfe3 in ofproto_port_set_state
> (port=port@entry=0x5634f52472f0, state=) at
> ofproto/ofproto.c:2485
> 
> 2018-12-04 21:23:59 josh #6  0x5634f35d07e3 in port_run
> (ofport=0x5634f52472e0) at ofproto/ofproto-dpif.c:3629
> 
> 2018-12-04 21:23:59 josh #7  run (ofproto_=0x5634f51dd2c0) at
> ofproto/ofproto-dpif.c:1666
> 
> 2018-12-04 21:23:59 josh #8  0x5634f35be5ee in ofproto_run
> (p=0x5634f51dd2c0) at ofproto/ofproto.c:1741
> 
> 2018-12-04 21:23:59 josh #9  0x5634f35abe9c in bridge_run__ () at
> vswitchd/bridge.c:2944
> 
> 2018-12-04 21:23:59 josh #10 0x5634f35b19e0 in bridge_run () at
> vswitchd/bridge.c:3002
> 
> 2018-12-04 21:23:59 josh #11 0x00005634f3211595 in main (argc= out>, argv=) at vswitchd/ovs-vswitchd.c:125
> 
> On Tue, Dec 11, 2018 at 7:50 AM Flavio Leitner  wrote:
> 
> > On Wed, Dec 05, 2018 at 12:11:28PM +1300, Josh Bailey via discuss wrote:
> > > Hello OVS colleagues,
> > >
> > > vswitchd appears to crash handling a port add/mod. Please see following
> > to
> > > reproduce.
> > >
> > > Run two Ryu OF controllers:
> > >
> > > $ ryu-manager --ofp-tcp-listen-port 6653  --ofp-listen-host 127.0.0.1
> > > --verbose --app-lists ryu.app.simple_switch_stp
> > >
> > > $ ryu-manager --ofp-tcp-listen-port 6654  --ofp-listen-host 127.0.0.1
> > > --verbose --app-lists ryu.app.simple_switch_stp
> > >
> > >
> > > Now set up a bridge with no interfaces:
> > >
> > >
> > > root@faucet:~/faucet# /usr/local/share/openvswitch/scripts/ovs-ctl start
> > > * Starting ovsdb-server
> > > * system ID not configured, please use --system-id
> > > * Configuring Open vSwitch system IDs
> > > * Starting ovs-vswitchd
> > > * Enabling remote OVSDB managers
> > > root@faucet:~/faucet# ovs-vsctl --version
> > > ovs-vsctl (Open vSwitch) 2.9.3
> > > DB Schema 7.15.1
> > > root@faucet:~/faucet# ovs-vsctl add-br br0
> > > root@faucet:~/faucet# ovs-vsctl set-controller br0 tcp:127.0.0.1:6653
> > tcp:
> > > 127.0.0.1:6654
> > >
> > >
> > > Now add a physical interface known to be up:
> > >
> > >
> > > root@faucet:~/faucet# ovs-vsctl add-port br0 enp2s0f0
> > >
> > >
> > > Observe crash in log:
> > >
> > >
> > > 2018-12-04T23:03:06.663Z|00036|bridge|INFO|bridge br0: added interface
> > > enp2s0f0 on port 1
> > > 2018-12-04T23:03:06.663Z|00037|bridge|INFO|bridge br0: using datapath ID
> > > 90e2ba7e7558
> > > 2018-12-04T23:03:06.663Z|00038|rconn|INFO|br0<->tcp:127.0.0.1:6653:
> > > disconnecting
> > > 2018-12-04T23:03:06.663Z|00039|rconn|INFO|br0<->tcp:127.0.0.1:6654:
> > > disconnecting
> > > 2018-12-04T23:03:06.664Z|00040|fail_open|WARN|Could not connect to
> > > controller (or switch failed controller's post-connection admission
> > control
> > > policy) for 19 seconds, failing open
> > > 2018-12-04T23:03:06.710Z|2|daemon_unix(monitor)|ERR|1 crashes: pid
> > 5620
> > > died, killed (Aborted), core dumped, restarting
> >
> > Please open the coredump using gdb and provide the backtrace at least,
> > Thanks,
> > --
> > fbl
> >
> >

-- 
Flavio

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

Re: [ovs-discuss] vhost-user multiqueue

[Flavio Leitner]

On Fri, Nov 23, 2018 at 03:25:02PM +0800, 梁永正 wrote:
> Hi
> 
>  I have met a problem.In function reconfigure_datapath, port->dynamic_txqs = 
> netdev_n_txq(port->netdev) < wanted_txqs; seems always be zero.
> 
>  If I want to enable multiqueue of the vhost-user device.Does the pmd-threads 
> must be the same number with the queues? Looking forward to your reply!

Which OVS version are you using?
The multiqueue is documented in the Documentation/.
fbl



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

Re: [ovs-discuss] Starting OVS w/ DPDK ...

[Flavio Leitner]

On Wed, Sep 12, 2018 at 09:21:18AM +0200, Andrzej Ostruszka wrote:
> Hello all
> 
> I'm new to OVS so please have some patience with me :)
> 
> What I'm trying to do is to start OVS with DPDK based ports.
> The actual setup is a board with Marvell's Armada 8040 chip.
> 
> I don't have any problems with starting DPDK based apps, it goes more or
> less like:
> - load required kernel modules (Marvell ones, specific for this chip)
> - start DPDK app and pass to EAL options to create correct vdev:
>   ./testpmd ... --vdev=eth_mvpp2,iface=eth0 ...
> 
> So my understanding is that I don't need any OVS specific kernel modules
> in order to use these ports via DPDK in OVS.  So I build OVS with option
> "--with-dpdk" but without "--with-linux" (as intro/install/dpdk.rst
> seems to suggest) [1].  Then I start the db:
> 
> # ovs-ctl --no-ovs-vswitchd start
> 
>  * Starting ovsdb-server
>  * system ID not configured, please use --system-id
>  * Configuring Open vSwitch system IDs
> 
> and indicate that I want to initialize DPDK:
> 
> # ovs-vsctl set Open_vSwitch . other_config:dpdk-init=true
> # ovs-vsctl get Open_vSwitch . other_config:dpdk-init
> "true"
> 
> but when I try to start the vswitchd I'm getting errors:
> 
> # ovs-ctl --no-ovsdb-server start

I don't know which OVS version is this and it may be because ovs-ctl
is trying to load the module or because ovs-vswitchd is doing that.
So, running sh -x ovs-ctl ... might shed a bit of light.

fbl

> 
> 
> modprobe: ERROR: ../libkmod/libkmod.c:586 kmod_search_moddep() could not
> open moddep file
> '/lib/modules/4.4.52-armada-17.10.4-g2dfc733/modules.dep.bin'
> modprobe: FATAL: Module openvswitch not found in directory
> /lib/modules/4.4.52-armada-17.10.4-g2dfc733
>  * Inserting openvswitch module
> rmmod: ERROR: ../libkmod/libkmod.c:514 lookup_builtin_file() could not
> open builtin file
> '/lib/modules/4.4.52-armada-17.10.4-g2dfc733/modules.builtin.bin'
> rmmod: ERROR: ../libkmod/libkmod-module.c:1921 kmod_module_get_holders()
> could not open '/sys/module/bridge/holders': No such file or directory
> rmmod: ERROR: Module bridge is in use
>  * removing bridge module
> 
> and obviously vswitchd is not running:
> # ovs-ctl status
> ovsdb-server is running with pid 7566
> ovs-vswitchd is not running
> 
> Why there are attempts to load some kernel modules?  How should I start
> vswitchd with DPDK based ports?  My expectation was that
> "dpdk-init=true" will indicate to ovs to not use any kernel modules and
> that I will be able later to add ports just like:
> 
> ovs-vsctl add-port br0 mrvl0 -- set Interface mrvl0 \
> type=dpdk options:dpdk-devargs=eth_mvpp20,iface=eth0
> ovs-vsctl add-port br0 mrvl2 -- set Interface mrvl2 \
> type=dpdk options:dpdk-devargs=eth_mvpp21,iface=eth2
> 
> I'd appreciate some tip/insight into what I am doing wrong and/or how
> can I debug this in order to solve it.
> 
> Best regards
> Andrzej
> 
> [1] Actually I'm cross compiling ovs, the full configure line is:
> ./configure CC=${CROSS}gcc --prefix=/usr/local/ovs
> --with-dpdk=${ROOTDIR}/marvell-dpdk/arm64-armv8a-linuxapp-gcc
> --host=aarch64-linux-gnu --disable-libcapng
> LDFLAGS="-L${ROOTDIR}/install/usr/local/lib -lmusdk"
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

-- 
Flavio

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

Re: [ovs-discuss] Starting OVS w/ DPDK ...

[Flavio Leitner]

On Thu, Sep 13, 2018 at 04:56:51PM +0200, Andrzej Ostruszka wrote:
> First of all, thank you for your reply Flavio.
> 
> On 12.09.2018 19:33, Flavio Leitner wrote:
> > On Wed, Sep 12, 2018 at 09:21:18AM +0200, Andrzej Ostruszka wrote:
> [...]
> >> but when I try to start the vswitchd I'm getting errors:
> >>
> >> # ovs-ctl --no-ovsdb-server start
> > 
> > I don't know which OVS version is this and it may be because ovs-ctl
> > is trying to load the module or because ovs-vswitchd is doing that.
> > So, running sh -x ovs-ctl ... might shed a bit of light.
> 
> The version is 2.9.2 (build from git tag v2.9.2 with the previously
> mentioned configure line).
> 
> This is the ovs-ctl that is unconditionally trying to load modules.
> 
> start -> start_ovsdb & start_forwarding
> start_forwarding -> do_start_forwarding -> insert_mod_if_required

Yeah, the initialization scripts doesn't know what is in the db, so
it seems convenient to just load the module.
 
> and "if_required" part of that function only skips loading if module is
> already present or there is no support in kernel for modules.  Below are
> some snippets from "sh -x
> /usr/local/ovs/share/openvswitch/scripts/ovs-ctl --no-ovsdb-server start"
[...]
> modprobe: ERROR: could not insert 'openvswitch': Unknown symbol in
> module, or unknown parameter (see d
> mesg)

You can work around that in modprobe.conf, e.g.:
install openvswitch /bin/true

> I'm not sure why openvswitch module is needed in case of using DPDK
> based ports.  That might be just the case of documentation not being up
> to date (in case it is needed) or missing checks in ovs-ctl (in case it
> can be skipped for DPDK based switching).

I suspect it is the latter.
 
> Anyway I've decided to reconfigure my kernel to match requirements of
> openvswitch module (some config options were missing) and now I have
> some progress (I load Marvell's modules, configure huge pages first,
> then I start db and set dpd-init to true - as previously):
> 
> # ovs-ctl --no-ovsdb-server start
>  * Starting ovs-vswitchd
> 
>  * Enabling remote OVSDB managers
> 
> # ovs-ctl status
> ovsdb-server is running with pid 2928
> 
> ovs-vswitchd is running with pid 3055
> 
> # ovs-vsctl show
> 78e4732f-e2e1-4784-971c-f4d67e163a26
> 
> Bridge "br0"
> 
> Port "br0"
> 
> Interface "br0"
> 
> type: internal
> 
> ovs_version: "2.9.2"
> 
> 
> so it looks like I'm good to go but I get problems when I try to add
> ports to it.

BTW the bridge 'br0' also needs to be in the userspace DP.

 
> # ovs-vsctl add-port br0 port0 -- set Interface port0 type=dpdk
> options:dpdk-devargs=eth_mvpp20,iface=eth0 ofport_request=1
> 
> [ 7156.926062] pgd = ffc23465a000
> 
> [ 7156.927215] pgd = ffc23465a000
> 
> [ 7156.927278] [0008] *pgd=000235346003, *pud=000235346003,
> *pmd=
> [ 7156.941365] [] *pgd=000235346003, *pud=000235346003,
> *pmd=
> [ 7161.622915] pgd = ffc1ddd54000
> 
> [ 7161.622938] [0008] *pgd=0001ddd55003, *pud=0001ddd55003,
> *pmd=
> 
> and I don't get command prompt again unless I interrupt with ^C.
> I have no idea what ofport_request=1 is for - I'm just copying from the
> docs (I assume this just gives id to port).  This type of log is

The ofport_request tells the switch that you want a specific OpenFlow
port ID for that port. If you don't provide it, then the vswitch will
get the next available to you.

> periodic - ovs-vswitchd seems to be crashing and is being periodically
> restarted.  In dmesg I see periodic entries as in [1] and in
> var/run/openvswitch I get ovs-vswitchd.PID.ctl sockets being added.
> 
> So I infer that for some reason vswitchd is crashing and I'd like to
> investigate that.  Any tips on how could I proceed with it?

Look at ovs-vswitchd.log and possibly the core dump file.

OVS can start the monitoring threads, then if the vswitchd crashes, it
will try to bring it up again.  There are some safe guards there to
avoid loops.

> Best regards
> Andrzej
> 
> [1] example of dmesg entry:
> --8<

I'd say to stop trying with OVS and try ``testpmd´´ from DPDK directly and
see if you can get it working. It is the simplest possible scenario
where you can tell that at least the bare bones are working.

> [10262.208121] CMA: total alloc 314, total free: 314 (garbage 1)
> [10271.717382] CMA buffer allocated: size = 41943040 Bytes, kvaddr =
> ffc1de5f6000, paddr = 0xb050
> 
> [10271.717458] CMA buffer remapped: vm_start=0x7f3c80, size

Re: [ovs-discuss] Connection to VM issue

[Flavio Leitner]

On Fri, Sep 14, 2018 at 11:22:55AM +, Polossat, Arnaud [FR] wrote:
> Hello,
> 
> I would like to connect a CentOS 7 virtual machine to an Open
> vSwitch 2.5.0 (OVS) with SSH. The OVS is installed on a CentOS 7
> physical server and the VM, which runs on the same server, is
> managed with VirtualBox. The interface in the OVS, called vnet7, is
> internal type, and has been added in VirtualBox as a Bridge.
> I put the IP address 10.0.0.8/28 in the OVS to enable it to
> communicate with the VM (the latter has the IP address 10.0.0.7/28).
> Here is a schema of the configuration:
> [Schema]

I don't know how VirtualBox will make it available through bridge but
sounds like you're seeing a routing issue. Though you say it's not.
On each side, run
# ip route get  

and check if the interface is indeed the correct one.


fbl

> 
> The setup of OVS is as follows:
> ovs-vsctl add-br ovs1
> ovs-vsctl add-port ovs1 vnet7
> ovs-vsctl set Interface vnet7 type=internal
> ip link set vnet7 up
> ip addr add 10.0.0.8/28 dev ovs1
> ip link set ovs1 up
> 
> In the server and the VM, ip routes are correct, there is no Iptables, 
> Firewalld is disabled and SELinux is in permissive mode.
> However, I do not manage to connect the VM to the OVS with SSH (or conversely 
> to connect the server with OVS to the VM) whereas Nmap shows that port 22 is 
> open.
> In addition, I completed several tests:
> 
> * I can ping the OVS from the VM, and the VM from the physical server.
> 
> * UDP traffic generated with Iperf from the VM to the server is also 
> working, but not conversely.
> 
> * If I connect another VM to the OVS (still installed on the same 
> server), the 2 VMs are able to communicate with TCP.
> 
> For example, a tcpdump in the server while launching a ssh 10.0.0.8 from the 
> VM shows:
> 
> [cid:image004.jpg@01D44C2E.0B4A1CC0]
> 
> The server receives SYN flags but doesn't reply with an ACK.
> 
> A tcpdump in the VM while launching a ssh 10.0.0.7 form the server with the 
> OVS shows:
> 
> [cid:image006.jpg@01D44C2E.0B4A1CC0]
> 
> Flags are diverse but the TCP session remains not established.
> 
> Surprisingly, the result differs sometimes. In the server after a ssh from 
> the VM:
> 
> [Tcpdump SSH server 2]
> 
> In the VM after a ssh from the server:
> 
> [Tcpdump SSH VM 2]
> 
> Do you have any idea about this kind of issue and the way to solve it?
> 
> Thank you very much in advance for answering my question.
> 
> Best regards,
> 
> Arnaud POLOSSAT
> Airbus Defence and Space
> 1, Bvd Jean Moulin, CS 40001
> 78 996 Elancourt Cedex, France
> E-mail: arnaud.polos...@fr.airbus.com
> 
> 
> ***
> Ce courriel (incluant ses eventuelles pieces jointes) peut contenir des 
> informations confidentielles et/ou protegees ou dont la diffusion est 
> restreinte. Si vous avez recu ce courriel par erreur, vous ne devez ni le 
> copier, ni l'utiliser, ni en divulguer le contenu a quiconque. Merci d'en 
> avertir immediatement l'expediteur et d'effacer ce courriel de votre systeme. 
> Airbus Defence and Space et les sociétés Airbus Group declinent toute 
> responsabilite en cas de corruption par virus, d'alteration ou de 
> falsification de ce courriel lors de sa transmission par voie electronique.
> This email (including any attachments) may contain confidential and/or 
> privileged information or information otherwise protected from disclosure. If 
> you are not the intended recipient, please notify the sender immediately, do 
> not copy this message or any attachments and do not use it for any purpose or 
> disclose its content to any person, but delete this message and any 
> attachments from your system. Airbus Defence and Space and Airbus Group 
> companies disclaim any and all liability if this email transmission was virus 
> corrupted, altered or falsified. 
> -
> Airbus Defence and Space SAS (393 341 516 RCS Toulouse) - Capital: 29.821.072 
> EUR - Siege social: 31 rue des Cosmonautes, ZI du Palays, 31402 Toulouse 
> cedex 4, France






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


-- 
Flavio


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

Re: [ovs-discuss] DPDK link state

[Flavio Leitner]

On Thu, Feb 21, 2019 at 02:58:16PM +0100, Riccardo Ravaioli wrote:
> Hi,
> 
> Let's say I have a basic setup with a Linux virtual machine with one
> vhostuser interface, a physical interface in DPDK mode, and an OVS switch
> with those two interfaces on it.
> Can the VM know when the link on the physical interface is up or down?

No, but it could ping some other remote host.

> I see that the command "ovs-ofctl show $bridge" reports this. I'm just not
> sure if the VM needs to be told explicitly (in which case, the command
> "ovs-ofctl mod-port $switch $port up/down" doesn't seem to work) or instead
> it has all the necessary means to know this through the DPDK library.

What exactly you're trying to do? The host networking could be seen as
the network infra outside of the host and in this case the VM link is
actually the vhost port which is up & running.

fbl

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

Re: [ovs-discuss] How to store the tcp_src or tcp_dst field value in a variable and then print in vlogs?

[Flavio Leitner]

On Tue, Feb 19, 2019 at 12:43:08PM +0800, Krish wrote:
> Hi Flavio,
> 
> I think I got tcp_src and tcp_dst values, I can also successfully print
> them.
> Here is what I did:
> for(numb=0;numb {
> 
> uint8_t nw_proto = 0;
> packet=packets->packets[numb];
> size_t size = dp_packet_size(packet);
> const void *data = dp_packet_data(packet);
> const char *frame = (const char *)data;
> dp_packet_reset_offsets(packet);
> *data_pull(, , ETH_ADDR_LEN * 2);*
> //dl_type = parse_ether(, );
> //VLOG_DBG("parse ether type DL TYPE: 0x%4x", dl_type);
> packet->l3_ofs = (char *)data - frame;
> const struct ip_header *ip = dp_packet_l3(packet);
> nw_proto = ip->ip_proto;
> VLOG_DBG("IP proto---> %d ", nw_proto);
> int ip_len;
> ip_len = IP_IHL(ip->ip_ihl_ver) * 4;
> 
> *data_pull(, , ip_len);*
> packet->l4_ofs = (char *)data - frame;
> if(nw_proto == 6)
> {
> struct tcp_header *th = dp_packet_l4(packet);
> VLOG_DBG( "tcp_src ---> %d", ntohs(th->tcp_src));
> VLOG_DBG( "tcp_dst ---> %d", ntohs(th->tcp_dst));
>   }
> }
> 
> 
> Can you please confirm, if this is the right approach I have used and not
> seeing the old values like before?

It's hard to read code using html (bold, etc), could you please use
text only and indent the code properly? It makes our life a lot easier.

When you pull ETH_ADDR_LEN*2, the offset now points to ethernet_type
which is not the l3_ofs as you set next. I don't think the above code
works unless you uncomment parse_ethertype() which pulls more 4 bytes.

fbl



> 
> Thank you so much,
> Krish
> 
> On Tue, Feb 19, 2019 at 11:25 AM Krish  wrote:
> 
> > Flavio,
> >
> > Thank you for the clarification. You explained it very well.
> >
> > I don't want to wait for the miniflow_extraction, so I am left with
> > parsing packet myself.
> >
> > Here is what I am doing now:
> >
> > for(numb=0;numb > {
> >
> > uint8_t nw_proto;
> > const char *frame;
> > packet=packets->packets[numb];
> > const void *data = dp_packet_data(packet);
> > frame = data;
> > *dp_packet_reset_offsets(packet);*
> > * packet->l3_ofs = (char *)data - frame;*
> > * const struct ip_header *ip = dp_packet_l3(packet);*
> > nw_proto = ip->ip_proto;
> > VLOG_DBG("IP proto---> %d ", nw_proto); // This is 0
> >
> > }
> >
> > I followed almost the same approach of what is going in miniflow_extract.
> > nw_proto(ip protocol) is printing out to be 0.
> > I am using this code just before emc_processing and inside
> > dp_netdev_input__.
> > Can you please help me here?
> >
> > Thanks
> > Krish
> >
> >
> > On Mon, Feb 18, 2019 at 8:11 PM Flavio Leitner  wrote:
> >
> >> On Mon, Feb 18, 2019 at 11:05:53AM +0800, Krish wrote:
> >> > Thanks for reply Ben.
> >> > Does it mean that *miniflow_extract* will also initialize the L3 header
> >> > pointer?
> >>
> >> If you look at the miniflow_extract(), you  will see that it calls
> >> dp_packet_reset_offsets(packet) which will set all the header pointers
> >> to their defaults meaning that they are not pointing to anything real.
> >>
> >> These pointers are used by dp_packet_l3 (or 4) functions to locate
> >> the header.
> >>
> >> Then if you continue following the function, you will notice that
> >> the code parses the packet from the outer header to the inner header
> >> and as the parser goes, it updates the header offsets, like this line:
> >>
> >> packet->l3_ofs = (char *)data - frame;
> >>
> >> At this point, you have the pointer to the l3 header and you could use
> >> dp_packet_l3().
> >>
> >>
> >> > But I am getting the correct values for *nw_proto* from the L3 header.
> >> > struct ip_header *ip = dp_packet_l3(packet);
> >> > nw_proto = ip->ip_proto;
> >> >
> >> > Any comments on this? Whether its right or wrong?
> >>
> >> When using DPDK, the packet is represented by two parts. One if the
> >> rte buffer (packet data) that comes from DPDK library and the second
> >> part is the packet's metadata (the offsets you need). This offsets
> >> are allocated in the stack at dp_netdev_process_rxq_port(), so most
> >> probably you are seeing old values from previous packets which
> >> happens to work, but they are not correct.
> >>
> >> As I said above miniflow_extract(

Re: [ovs-discuss] [HELP] Question about Performance issues in high concurrency scenarios

[Flavio Leitner]

On Tue, Mar 05, 2019 at 03:38:43PM +0800, txfh2007 via discuss wrote:
> Hi everyone:
>  I have test ovs-dpdk PVP performance for several days . And I
>  have found in high concurrency scenarios(eg. 100K mac-ip
>  streams), the ovs-dpdk performance gets significant decline.
>  And one cause of performance decline is the emc entry num
>  limitation, is that right? If I just increase emc entry num,
>  will other problems occur ? Are there any suggession helping to
>  get performance improvement under high concurrency scenarios?
 

Perhaps you could consider disabling EMC if its size is not enough.
fbl

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

Re: [ovs-discuss] Unable to add VM with tap interface to OVS using libvrt

[Flavio Leitner]

On Wed, Mar 06, 2019 at 06:40:58PM +0530, Harsh Gondaliya wrote:
> I want to attach two VMs to OVS using libvrt. I am following these steps:
> http://docs.openvswitch.org/en/latest/howto/libvirt/
> 
> I have OVS with DPDK configuration running. I have created br0 bridge
> without mentioned datapath_type=netdev, i.e. I do not want to use DPDJ=K
> datapath for this testing that I am doing currently. Also, the physical NIC
> is attached to my br0 bridge. After I change the XML file following error
> message pops up in Virtual Machine Manager:

Can you share the xml?


> *Error starting domain: internal error: Unable to add port vnet0 to OVS
> bridge br0*
> *Details:*
> Traceback (most recent call last):
>   File "/usr/share/virt-manager/virtManager/asyncjob.py", line 90, in
> cb_wrapper
> callback(asyncjob, *args, **kwargs)
>   File "/usr/share/virt-manager/virtManager/asyncjob.py", line 126, in tmpcb
> callback(*args, **kwargs)
>   File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 83, in
> newfn
> ret = fn(self, *args, **kwargs)
>   File "/usr/share/virt-manager/virtManager/domain.py", line 1402, in
> startup
> self._backend.create()
>   File "/usr/lib/python2.7/dist-packages/libvirt.py", line 1035, in create
> if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
> libvirtError: internal error: Unable to add port vnet0 to OVS bridge br0
> 
> I am not able to figure out how to get this error sorted out. Any help in
> this regard would be great.
> 
> Regards,
> Harsh

> ___
> 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] Phy-VM over OVS-DPDK no connectivity

[Flavio Leitner]

On Tue, Mar 05, 2019 at 03:17:04PM +0530, ppnaik wrote:
> Hi All,
> 
> Our setup is as follows:
> 
> We have two servers which are connected peer to peer over 40G interfaces.
> 
> On one server we have setup OVS and added the physical 40G interface as a
> DPDK interface to the ovs bridge.
> 
> We created another dpdkvhostuser interface for the VM. We added this
> interface to the VM (by editing the XML). We are able to see this interface
> inside the VM and have configure IP to the interface.
> 
> We want to communicate between the other server and VM inside this server
> through the OVS interface created for the VM.
> 
> The steps we followed (on the server with OVS) are:
> 
> modprobe uio
> 
> cd /usr/src/dpdk-18.11/x86_64-native-linuxapp-gcc/kmod/
> 
> insmod igb_uio.ko

VFIO is safer than UIO.

Please check out our guides at:
https://github.com/openvswitch/ovs/blob/master/Documentation/intro/install/dpdk.rst
https://github.com/openvswitch/ovs/blob/master/Documentation/howto/dpdk.rst

You might want to try PHY-to-PHY first to make sure your basic
plumbing is okay and then add the VM.
fbl



> cd /usr/src/dpdk-18.11/usertools/
> ./dpdk-devbind.py --bind=igb_uio :81:00.1
> 
>  export PATH=$PATH:/usr/local/share/openvswitch/scripts
>  export DB_SOCK=/usr/local/var/run/openvswitch/db.sock
> 
>  ovsdb-server --remote=punix:/usr/local/var/run/openvswitch/db.sock
> --remote=db:Open_vSwitch,Open_vSwitch,manager_options
> --private-key=db:Open_vSwitch,SSL,private_key
> --certificate=db:Open_vSwitch,SSL,certificate
> --bootstrap-ca-cert=db:Open_vSwitch,SSL,ca_cert --pidfile --detach
> --log-file
> 
>  ovs-vsctl --no-wait set Open_vSwitch . other_config:dpdk-init=true
>  ovs-ctl --no-ovsdb-server --db-sock="$DB_SOCK" start
> 
> ovs-vsctl add-br br0 -- set bridge br0 datapath_type=netdev
> ovs-vsctl add-port br0 dpdk-p0 -- set Interface dpdk-p0 type=dpdk
> options:dpdk-devargs=:81:00.1
> ovs-vsctl add-port br0 dpdkvhostuser0 -- set Interface dpdkvhostuser0
> type=dpdkvhostuser ofport_request=3
> 
> ovs-ofctl add-flow br0 in_port=1,action=output:3
> ovs-ofctl add-flow br0 in_port=3,action=output:1
> 
> echo 'vm.nr_hugepages=2048' > /etc/sysctl.d/hugepages.conf
> grep HugePages_ /proc/meminfo
> 
> edit VM XML to add this interface:
> 
> first line:
> 
> 
> add before  tag:
> 
> 
> 
>  value='socket,id=char1,path=/usr/local/var/run/openvswitch/dpdkvhostuser0'/>
> 
>  value='vhost-user,id=mynet1,chardev=char1,vhostforce=on,queues=1'/>
> 
>  value='virtio-net-pci,mac=00:00:00:00:00:02,netdev=mynet1,mq=on,vectors=4'/>
> 
> 
> 
>  value='memory-backend-file,id=mem1,size=4096M,mem-path=/dev/hugepages,share=on'/>
> 
> 
> 
>   
> 
> Please help us resolve this issue. I assumed ping would work between the
> other server and the VM. But it is not working in our case. Also, let us
> know if we are missing some setup step or if there is some misconfiguration.
> If ping would not work can you let us know a way to verify the connectivity?
> 
> Thanks,
> Priyanka
> 
> ___
> 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] How to store the tcp_src or tcp_dst field value in a variable and then print in vlogs?

[Flavio Leitner]

On Mon, Feb 18, 2019 at 11:05:53AM +0800, Krish wrote:
> Thanks for reply Ben.
> Does it mean that *miniflow_extract* will also initialize the L3 header
> pointer?

If you look at the miniflow_extract(), you  will see that it calls
dp_packet_reset_offsets(packet) which will set all the header pointers
to their defaults meaning that they are not pointing to anything real.

These pointers are used by dp_packet_l3 (or 4) functions to locate
the header.

Then if you continue following the function, you will notice that
the code parses the packet from the outer header to the inner header
and as the parser goes, it updates the header offsets, like this line:

packet->l3_ofs = (char *)data - frame;

At this point, you have the pointer to the l3 header and you could use
dp_packet_l3().


> But I am getting the correct values for *nw_proto* from the L3 header.
> struct ip_header *ip = dp_packet_l3(packet);
> nw_proto = ip->ip_proto;
> 
> Any comments on this? Whether its right or wrong?

When using DPDK, the packet is represented by two parts. One if the
rte buffer (packet data) that comes from DPDK library and the second
part is the packet's metadata (the offsets you need). This offsets
are allocated in the stack at dp_netdev_process_rxq_port(), so most
probably you are seeing old values from previous packets which
happens to work, but they are not correct.

As I said above miniflow_extract() initializes those offsets to a
known state and then parse the packet to update with the correct
values.

In summary, you will need to either wait for miniflow_extract() or
parse the packet yourself if you need the tcp port.

HTH,
fbl



> 
> Thanks a lot for your patience and response.
> 
> Regards
> 
> Krish
> 
> On Sat, Feb 16, 2019 at 10:09 AM Ben Pfaff  wrote:
> 
> > You are almost certainly dereferencing a null pointer.
> >
> > On Sat, Feb 16, 2019 at 09:02:17AM +0800, Krish wrote:
> > > That code I showed before. It is working fine and crashing only when I
> > > enable debugging.
> > >
> > > As *sruct tcp_header's tcp_src* has ovs_be16 type. How to store and print
> > > this value ?
> > >
> > > Thanks
> > >
> > > On Sat, Feb 16, 2019, 08:43 Ben Pfaff  wrote:
> > >
> > > > Then you're going to have to work harder since miniflow_extract() is
> > > > what initializes the L4 header pointer.
> > > >
> > > > On Sat, Feb 16, 2019 at 08:39:08AM +0800, Krish wrote:
> > > > > I am sorry, but I am trying not to use extracted flow.  I want to use
> > > > this
> > > > > information before it goes to EMC.
> > > > >
> > > > >
> > > > >
> > > > > On Sat, Feb 16, 2019, 03:44 Ben Pfaff  wrote:
> > > > >
> > > > > > On Fri, Feb 15, 2019 at 03:48:22PM +0800, Krish wrote:
> > > > > > > Hi
> > > > > > >
> > > > > > > I want to store tcp_src, dst port in a variable.
> > > > > > > This is what I am doing:
> > > > > > > 1. Retrieve packet from dp_packet_batch one by one.
> > > > > > > 2. Retrieving field values by extracting packets headers:
> > > > > > >
> > > > > > > struct ip_header *ip = dp_packet_l3(packet);
> > > > > > > nw_proto = ip->ip_proto;
> > > > > > > if(nw_proto == 6)
> > > > > > > {
> > > > > > > struct tcp_header *th = dp_packet_l4(packet);
> > > > > > > // The following are the 2 different ways I am trying to print
> > the
> > > > > > tcp_src.
> > > > > > > I have tried it 1 and 2 separately not at the same time.
> > > > > > > //1 . Ovs crash at the below statement
> > > > > > > uint16_t src = (uint16_t) ntohs(th->tcp_src);
> > > > > > > VLOG_DBG( "tcp_src ---> %d", src );
> > > > > > > //2. When I enable logging ovs crashes at this
> > point
> > > > > > > VLOG_DBG( "tcp_src ---> %d", ntohs(th->tcp_src)
> > );
> > > > > > >
> > > > > > >
> > > > > > >  }
> > > > > > >
> > > > > > > Can anyone please help how to store tcp_src port value in a
> > variable
> > > > and
> > > > > > > print it in vlogs?
> > > > > > > Statement 2 is working fine if vlogs are disabled, but I want the
> > > > port
> > > > > > > value to be stored in a variable and then print.
> > > > > >
> > > > > > I'd just get it from the extracted flow instead of inventing new
> > code
> > > > to
> > > > > > extract it.
> > > > > >
> > > >
> >

> ___
> 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-vswitchd exited silently

[Flavio Leitner]

On Thu, Sep 05, 2019 at 09:18:22AM +, Frank Wang(王培辉) wrote:
> Hi All

Hi Franck,

Perhaps check the permissions of /var/run/openvswitch ?

If they are correct, you can start ovsdb-server service first and
then start the ovs-vswitchd manually as the service does.

fbl

> 
> 
> 
>  I’m encountered a very strange problem that ovs-vswitchd exited 
> silently without any exceptions while ovsdb-server running normally, I’m 
> using openvswitch 2.9.2
> 
> I didn’t find any valuable log except that
> 
> ovs|1|unixctl|WARN|failed to connect to 
> /var/run/openvswitch/ovs-vswitchd.5168.ctl
> 
> ovs-ctl[303320]: 2019-09-05T03:12:28Z|1|unixctl|WARN|failed to connect to 
> /var/run/openvswitch/ovs-vswitchd.5168.ctl
> 
> ovs-ctl[303320]: ovs-appctl: cannot connect to 
> "/var/run/openvswitch/ovs-vswitchd.5168.ctl" (Connection refused)
> 
> 
> 
> See the details below.
> 
> 
> 
> [root@node-34435-75174 ~]# systemctl status ovs-vswitchd -l
> 
> ● ovs-vswitchd.service - Open vSwitch Forwarding Unit
> 
>Loaded: loaded (/usr/lib/systemd/system/ovs-vswitchd.service; static; 
> vendor preset: disabled)
> 
>Active: inactive (dead) since Thu 2019-09-05 11:12:28 CST; 4h 4min ago
> 
>   Process: 303320 ExecStop=/usr/share/openvswitch/scripts/ovs-ctl 
> --no-ovsdb-server stop (code=exited, status=0/SUCCESS)
> 
> 
> 
> Aug 27 11:09:13 node-34435-75174 systemd[1]: Starting Open vSwitch Forwarding 
> Unit...
> 
> Aug 27 11:09:13 node-34435-75174 ovs-ctl[5105]: Inserting openvswitch module 
> [  OK  ]
> 
> Aug 27 11:09:13 node-34435-75174 ovs-ctl[5105]: Starting ovs-vswitchd [  OK  ]
> 
> Aug 27 11:09:13 node-34435-75174 ovs-vsctl[5257]: ovs|1|vsctl|INFO|Called 
> as ovs-vsctl --no-wait set Open_vSwitch . 
> external-ids:hostname=node-34435-75174
> 
> Aug 27 11:09:13 node-34435-75174 ovs-ctl[5105]: Enabling remote OVSDB 
> managers [  OK  ]
> 
> Aug 27 11:09:13 node-34435-75174 systemd[1]: Started Open vSwitch Forwarding 
> Unit.
> 
> Sep 05 11:12:28 node-34435-75174 ovs-appctl[30]: 
> ovs|1|unixctl|WARN|failed to connect to 
> /var/run/openvswitch/ovs-vswitchd.5168.ctl
> 
> Sep 05 11:12:28 node-34435-75174 ovs-ctl[303320]: 
> 2019-09-05T03:12:28Z|1|unixctl|WARN|failed to connect to 
> /var/run/openvswitch/ovs-vswitchd.5168.ctl
> 
> Sep 05 11:12:28 node-34435-75174 ovs-ctl[303320]: ovs-appctl: cannot connect 
> to "/var/run/openvswitch/ovs-vswitchd.5168.ctl" (Connection refused)
> 
> 
> 
> [root@node-34435-75174 ~]# ls /var/run/openvswitch/ -l
> 
> total 12
> 
> srwxr-x---. 1 openvswitch openvswitch  0 Aug 27 11:09 db.sock
> 
> srwxr-x---. 1 openvswitch openvswitch  0 Aug 27 11:09 managevSwitch.mgmt
> 
> srwxr-x---. 1 openvswitch openvswitch  0 Aug 27 11:09 managevSwitch.snoop
> 
> srwxr-x---. 1 openvswitch openvswitch  0 Aug 27 11:09 ovsdb-server.5084.ctl
> 
> -rw-r--r--. 1 openvswitch openvswitch  5 Aug 27 11:09 ovsdb-server.pid
> 
> srwxr-x---. 1 openvswitch openvswitch  0 Aug 27 11:09 ovs-vswitchd.5168.ctl
> 
> -rw-r--r--. 1 openvswitch openvswitch  5 Aug 27 11:09 ovs-vswitchd.pid
> 
> srwxr-x---. 1 openvswitch openvswitch  0 Aug 27 11:09 sw-01.mgmt
> 
> srwxr-x---. 1 openvswitch openvswitch  0 Aug 27 11:09 sw-01.snoop
> 
> -rw-r--r--. 1 rootroot43 Aug 27 11:09 useropts
> 
> 
> 
> cat /var/log/message
> 
> Sep  5 11:00:01 node-34435-75174 systemd: Removed slice User Slice of root.
> 
> Sep  5 11:01:01 node-34435-75174 systemd: Created slice User Slice of root.
> 
> Sep  5 11:01:01 node-34435-75174 systemd: Started Session 1530 of user root.
> 
> Sep  5 11:01:01 node-34435-75174 systemd: Removed slice User Slice of root.
> 
> Sep  5 11:10:01 node-34435-75174 systemd: Created slice User Slice of root.
> 
> Sep  5 11:10:01 node-34435-75174 systemd: Started Session 1531 of user root.
> 
> Sep  5 11:10:01 node-34435-75174 systemd: Removed slice User Slice of root.
> 
> Sep  5 11:12:28 node-34435-75174 ovs-appctl: ovs|1|unixctl|WARN|failed to 
> connect to /var/run/openvswitch/ovs-vswitchd.5168.ctl
> 
> Sep  5 11:12:28 node-34435-75174 ovs-ctl: 
> 2019-09-05T03:12:28Z|1|unixctl|WARN|failed to connect to 
> /var/run/openvswitch/ovs-vswitchd.5168.ctl
> 
> Sep  5 11:12:28 node-34435-75174 ovs-ctl: ovs-appctl: cannot connect to 
> "/var/run/openvswitch/ovs-vswitchd.5168.ctl" (Connection refused)
> 
> Sep  5 11:20:01 node-34435-75174 systemd: Created slice User Slice of root.
> 
> Sep  5 11:20:01 node-34435-75174 systemd: Started Session 1532 of user root.
> 
> Sep  5 11:20:01 node-34435-75174 systemd: Removed slice User Slice of root.
> 
> Sep  5 11:24:12 node-34435-75174 systemd: Starting Cleanup of Temporary 
> Directories...
> 
> Sep  5 11:24:12 node-34435-75174 systemd: Started Cleanup of Temporary 
> Directories.
> 
> Sep  5 11:30:01 node-34435-75174 systemd: Created slice User Slice of root.
> 
> Sep  5 11:30:01 node-34435-75174 systemd: Started Session 1533 of user root.
> 
> Sep  5 11:30:01 node-34435-75174 systemd: Removed slice User Slice of root.
> 
> 

Re: [ovs-discuss] gso packet is failing with af_packet socket with packet_vnet_hdr

[Flavio Leitner]

On Mon, 4 Nov 2019 21:32:28 +0530
Ramana Reddy  wrote:

> Hi Favio Leitner,
> Thank you very much for your reply. Here is the code snippet. But the
> same code is working if I send the packet without ovs.

Could you provide more details on the OvS environment and the test?

The linux kernel propagates the header size dependencies when you stack
the devices in net_device->hard_header_len, so in the case of vxlan dev
it will be:

needed_headroom = lowerdev->hard_header_len;
needed_headroom += VXLAN_HEADROOM;
dev->needed_headroom = needed_headroom;

Sounds like that is helping when OvS is not being used.

fbl


> bool csum = true;
> bool gso = true'
>  struct virtio_net_hdr *vnet = buf;
>if (csum) {
> vnet->flags = (VIRTIO_NET_HDR_F_NEEDS_CSUM);
> vnet->csum_start = ETH_HLEN + sizeof(*iph);
> vnet->csum_offset = __builtin_offsetof(struct
> tcphdr, check);
> }
> 
> if (gso) {
> vnet->hdr_len = ETH_HLEN + sizeof(*iph) +
> sizeof(*tcph);
> vnet->gso_type = VIRTIO_NET_HDR_GSO_TCPV4;
> vnet->gso_size = ETH_DATA_LEN - sizeof(struct
> iphdr) -
> sizeof(struct
> tcphdr);
> } else {
> vnet->gso_type = VIRTIO_NET_HDR_GSO_NONE;
> }
> Regards,
> Ramana
> 
> 
> On Mon, Nov 4, 2019 at 8:39 PM Flavio Leitner 
> wrote:
> 
> >
> > Hi,
> >
> > What's the value you're passing on gso_size in struct
> > virtio_net_hdr? You need to leave room for the encapsulation
> > header, e.g.:
> >
> > gso_size = iface_mtu - virtio_net_hdr->hdr_len
> >
> > fbl
> >
> > On Mon, 4 Nov 2019 01:11:36 +0530
> > Ramana Reddy  wrote:
> >  
> > > Hi,
> > > I am wondering if anyone can help me with this. I am having
> > > trouble to send tso/gso packet
> > > with af_packet socket with packet_vnet_hdr (through
> > > virtio_net_hdr) over vxlan tunnel in OVS.
> > >
> > > What I observed that, the following function eventually hitting
> > > and is returning false (net/core/skbuff.c), hence the packet is
> > > dropping. static inline bool skb_gso_size_check(const struct
> > > sk_buff *skb, unsigned int seg_len,
> > >   unsigned int max_len) {
> > > const struct skb_shared_info *shinfo = skb_shinfo(skb);
> > > const struct sk_buff *iter;
> > > if (shinfo->gso_size != GSO_BY_FRAGS)
> > > return seg_len <= max_len;
> > > ..
> > > }
> > > [  678.756673] ip_finish_output_gso:235 packet_length:2762 (here
> > > packet_length = skb->len - skb_inner_network_offset(skb))
> > > [  678.756678] ip_fragment:510 packet length:1500
> > > [  678.756715] ip_fragment:510 packet length:1314
> > > [  678.956889] skb_gso_size_check:4474 and seg_len:1550 and
> > > max_len:1500 and shinfo->gso_size:1448 and GSO_BY_FRAGS:65535
> > >
> > > Observation:
> > > When we send the large packet ( example here is
> > > packet_length:2762), its showing the seg_len(1550) >
> > > max_len(1500). Hence return seg_len <= max_len statement
> > > returning false. Because of this, ip_fragment calling
> > > icmp_send(skb, ICMP_DEST_UNREACH, ICMP_FRAG_NEEDED, htonl(mtu));
> > > rather the code reaching to ip_finish_output2(sk, skb)
> > > function in net/ipv4/ip_output.c and is given below:
> > >
> > > static int ip_finish_output_gso(struct sock *sk, struct sk_buff
> > > *skb, unsigned int mtu)
> > > {
> > > netdev_features_t features;
> > > struct sk_buff *segs;
> > > int ret = 0;
> > >
> > > /* common case: seglen is <= mtu */
> > > if (skb_gso_validate_mtu(skb, mtu))
> > > return ip_finish_output2(sk, skb);
> > >...
> > >   err = ip_fragment(sk, segs, mtu, ip_finish_output2);
> > >   ...
> > >  }
> > >
> > > But when we send normal iperf traffic ( gso/tso  traffic) over
> > > vxlan, the skb_gso_size_check returning a true value, and
> > > ip_finish_output2 getting executed.
> > > Here is the values of normal iperf traffic over vxlan.
> > >
> > > [ 1041.400537] skb_gso_size_check:4477 and seg_len:1500 and
> > > 

Re: [ovs-discuss] OVS deleting flows from the datapath on exit

[Flavio Leitner]

On Fri, 1 Nov 2019 13:35:07 -0700
Ben Pfaff  wrote:

> OVS currently can gracefully exit in two ways: either with or without
> deleting the datapath.  But, either way, it deletes all of the flows
> from the datapath before it exits.  That is due to commit e96a5c24e853
> ("upcall: Remove datapath flows when setting n-threads."), which was
> first released in OVS 2.1 back in 2014.
> 
> This isn't usually a big deal.  However, some controller folks I'm
> talking to are concerned about upgrade.  If the datapath flows
> persisted after OVS exits, then existing network connections (and
> perhaps some that are "similar" to them because they match the same
> megaflows) could carry on while the upgrade was in progress.  
> 
> I am surprised that I have not heard complaints about this in the 5
> years that the behavior has been this way.  Does anyone have any
> stories to report about it now that I bring it up?  Contrariwise, if
> we changed OVS so that it did not delete datapath flows on exit, can
> anyone suggest what problems that might cause?

Well, I heard complains about updating OvS package causing a long
downtime in OSP environments mainly because all the flows needed to be
rebuilt at OSP side which was a slow process.

When a service is restarted, it is expected to come up with a "clean
and fresh state" and so far flows were seen as "temporary" data. In
order to provide the option to restore the flows, the following commit
was introduced to create a "reload" service:
  commit ea36b04688f37cf45b7c2304ce31f0d29f212d54
  Author: Timothy Redaelli 
  Date:   Fri Nov 3 21:39:17 2017 +0100

  rhel: Add support for "systemctl reload openvswitch"

Now the openvswitch service could be restarted with flows persisting.

There was also an investigation to preserve the kernel datapath cache
during the reload to be less disruptive as possible. However after the
above commit I never heard about package update issues again, so we
dropped the kernel datapath persistent effort.

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

Re: [ovs-discuss] OVS DPDK: Failed to create memory pool for netdev

[Flavio Leitner]

It would be nice if you share the DPDK options used in OvS.

On Sat, 2 Nov 2019 15:43:18 +
"Tobias Hofmann \(tohofman\) via discuss" 
wrote:

> Hello community,
> 
> My team and I observe a strange behavior on our system with the
> creation of dpdk ports in OVS. We have a CentOS 7 system with
> OpenvSwitch and only one single port of type ‘dpdk’ attached to a
> bridge. The MTU size of the DPDK port is 9216 and the reserved
> HugePages for OVS are 512 x 2MB-HugePages, e.g. 1GB of total HugePage
> memory.
> 
> Setting everything up works fine, however after I reboot my box, the
> dpdk port is in error state and I can observe this line in the logs
> (full logs attached to the mail):
> 2019-11-02T14:46:16.914Z|00437|netdev_dpdk|ERR|Failed to create
> memory pool for netdev dpdk-p0, with MTU 9216 on socket 0: Invalid
> argument 2019-11-02T14:46:16.914Z|00438|dpif_netdev|ERR|Failed to set
> interface dpdk-p0 new configuration
> 
> I figured out that by restarting the openvswitch process, the issue
> with the port is resolved and it is back in a working state. However,
> as soon as I reboot the system a second time, the port comes up in
> error state again. Now, we have also observed a couple of other
> workarounds that I can’t really explain why they help:
> 
>   *   When there is also a VM deployed on the system that is using
> ports of type ‘dpdkvhostuserclient’, we never see any issues like
> that. (MTU size of the VM ports is 9216 by the way)
>   *   When we increase the HugePage memory for OVS to 2GB, we also
> don’t see any issues.
>   *   Lowering the MTU size of the ‘dpdk’ type port to 1500 also
> helps to prevent this issue.
> 
> Can anyone explain this?
> 
> We’re using the following versions:
> Openvswitch: 2.9.3
> DPDK: 17.11.5
> 
> Appreciate any help!
> Tobias

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

Re: [ovs-discuss] gso packet is failing with af_packet socket with packet_vnet_hdr

[Flavio Leitner]

Hi,

What's the value you're passing on gso_size in struct virtio_net_hdr?
You need to leave room for the encapsulation header, e.g.:

gso_size = iface_mtu - virtio_net_hdr->hdr_len

fbl

On Mon, 4 Nov 2019 01:11:36 +0530
Ramana Reddy  wrote:

> Hi,
> I am wondering if anyone can help me with this. I am having trouble
> to send tso/gso packet
> with af_packet socket with packet_vnet_hdr (through virtio_net_hdr)
> over vxlan tunnel in OVS.
> 
> What I observed that, the following function eventually hitting and is
> returning false (net/core/skbuff.c), hence the packet is dropping.
> static inline bool skb_gso_size_check(const struct sk_buff *skb,
>   unsigned int seg_len,
>   unsigned int max_len) {
> const struct skb_shared_info *shinfo = skb_shinfo(skb);
> const struct sk_buff *iter;
> if (shinfo->gso_size != GSO_BY_FRAGS)
> return seg_len <= max_len;
> ..
> }
> [  678.756673] ip_finish_output_gso:235 packet_length:2762 (here
> packet_length = skb->len - skb_inner_network_offset(skb))
> [  678.756678] ip_fragment:510 packet length:1500
> [  678.756715] ip_fragment:510 packet length:1314
> [  678.956889] skb_gso_size_check:4474 and seg_len:1550 and
> max_len:1500 and shinfo->gso_size:1448 and GSO_BY_FRAGS:65535
> 
> Observation:
> When we send the large packet ( example here is packet_length:2762),
> its showing the seg_len(1550) > max_len(1500). Hence return seg_len
> <= max_len statement returning false.
> Because of this, ip_fragment calling icmp_send(skb, ICMP_DEST_UNREACH,
> ICMP_FRAG_NEEDED, htonl(mtu)); rather the code reaching to
> ip_finish_output2(sk, skb)
> function in net/ipv4/ip_output.c and is given below:
> 
> static int ip_finish_output_gso(struct sock *sk, struct sk_buff *skb,
> unsigned int mtu)
> {
> netdev_features_t features;
> struct sk_buff *segs;
> int ret = 0;
> 
> /* common case: seglen is <= mtu */
> if (skb_gso_validate_mtu(skb, mtu))
> return ip_finish_output2(sk, skb);
>...
>   err = ip_fragment(sk, segs, mtu, ip_finish_output2);
>   ...
>  }
> 
> But when we send normal iperf traffic ( gso/tso  traffic) over vxlan,
> the skb_gso_size_check returning a true value, and ip_finish_output2
> getting executed.
> Here is the values of normal iperf traffic over vxlan.
> 
> [ 1041.400537] skb_gso_size_check:4477 and seg_len:1500 and
> max_len:1500 and shinfo->gso_size:1398 and GSO_BY_FRAGS:65535
> [ 1041.400587] skb_gso_size_check:4477 and seg_len:1450 and
> max_len:1450 and shinfo->gso_size:1398 and GSO_BY_FRAGS:65535
> [ 1041.400594] skb_gso_size_check:4477 and seg_len:1500 and
> max_len:1500 and shinfo->gso_size:1398 and GSO_BY_FRAGS:65535
> [ 1041.400732] skb_gso_size_check:4477 and seg_len:1450 and
> max_len:1450 and shinfo->gso_size:1398 and GSO_BY_FRAGS:65535
> [ 1041.400741] skb_gso_size_check:4477 and seg_len:1450 and
> max_len:1450 and shinfo->gso_size:1398 and GSO_BY_FRAGS:65535
> 
> Can someone help me to solve what is missing, and where should I
> modify the code in OVS/ or outside of ovs, so that it works as
> expected.
> 
> Thanks in advance.
> 
> Some more info:
> [root@xx ~]# uname -r
> 3.10.0-1062.4.1.el7.x86_64
> [root@xx ~]# cat /etc/redhat-release
> Red Hat Enterprise Linux Server release 7.7 (Maipo)
> 
> [root@xx]# ovs-vsctl --version
> ovs-vsctl (Open vSwitch) 2.9.0
> DB Schema 7.15.1
> 
> And dump_stack output with af_packet:
> [ 4833.637460][] dump_stack+0x19/0x1b
> [ 4833.637474]  []
> ip_fragment.constprop.55+0xc3/0x141 [ 4833.637481]
> [] ip_finish_output+0x314/0x350 [ 4833.637484]
> [] ip_output+0xb3/0x130 [ 4833.637490]
> [] ? ip_do_fragment+0x910/0x910 [ 4833.637493]
> [] ip_local_out_sk+0xf9/0x180 [ 4833.637497]
> [] iptunnel_xmit+0x18c/0x220 [ 4833.637505]
> [] udp_tunnel_xmit_skb+0x117/0x130 [udp_tunnel]
> [ 4833.637538]  [] vxlan_xmit_one+0xb6a/0xb70
> [vxlan] [ 4833.637545]  [] ?
> vprintk_default+0x29/0x40 [ 4833.637551]  []
> vxlan_xmit+0xc9e/0xef0 [vxlan] [ 4833.637555]  [] ?
> kfree_skbmem+0x37/0x90 [ 4833.637559]  [] ?
> consume_skb+0x34/0x90 [ 4833.637564]  [] ?
> packet_rcv+0x4c/0x3e0 [ 4833.637570]  []
> dev_hard_start_xmit+0x246/0x3b0 [ 4833.637574]  []
> __dev_queue_xmit+0x519/0x650 [ 4833.637580]  [] ?
> try_to_wake_up+0x190/0x390 [ 4833.637585]  []
> dev_queue_xmit+0x10/0x20 [ 4833.637592]  []
> ovs_vport_send+0xa6/0x180 [openvswitch] [ 4833.637599]
> [] do_output+0x4e/0xd0 [openvswitch] [ 4833.637604]
>  [] do_execute_actions+0xa29/0xa40 [openvswitch]
> [ 4833.637610]  [] ? __wake_up_common+0x82/0x120
> [ 4833.637615]  [] ovs_execute_actions+0x4c/0x140
> [openvswitch]
> [ 4833.637621]  [] ovs_dp_process_packet+0x84/0x120
> [openvswitch]
> [ 4833.637627]  [] ? ovs_ct_update_key+0xc4/0x150
> [openvswitch]
> [ 4833.637633]  [] ovs_vport_receive+0x73/0xd0
> [openvswitch]
> [ 4833.637638]  

Re: [ovs-discuss] gso packet is failing with af_packet socket with packet_vnet_hdr

[Flavio Leitner]

On Wed, 6 Nov 2019 01:59:41 +0530
Ramana Reddy  wrote:

> Hi Flavio,
> As per your inputs, I modified the gso_size, and now
> skb_gso_validate_mtu(skb, mtu) is returning true, and
> ip_finish_output2(sk, skb)  and dst_neigh_output(dst, neigh, skb); are
> getting called. But still, I am seeing the large packets getting
> dropped somewhere in the kernel
> down the line and retransmission happening.

The gso_size is the size of the data payload, so it doesn't account the
headers. Usually this depends on the iface MTU like I pointed before and
that MTU should account for the encapsulation later on. For example:

veth0(1450)veth1(1450) -- VXLAN(64k) --- eth0(1500)

Perhaps you can use ``dropwatch´´ to find out where the packet is
dropped.

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

Re: [ovs-discuss] OVS DPDK: Failed to create memory pool for netdev

[Flavio Leitner]

On Tue, 5 Nov 2019 18:47:09 +
"Tobias Hofmann \(tohofman\) via discuss" 
wrote:

> Hi Flavio,
> 
> thanks for the insights! Unfortunately, I don't know about the pdump
> and its relation to the ring.

pdump dumps packets from dpdk ports into rings/mempools, so that you
can inspect/use the traffic:
https://doc.dpdk.org/guides/howto/packet_capture_framework.html

But I looked at the dpdk sources now and I don't see it allocating any
memory when the library is initialized, so this is likely a red herring.

> Can you please specify where I can see that the port is not ready
> yet? Is that these three lines:
> 
> 2019-11-02T14:14:23.094Z|00070|dpdk|ERR|EAL: Cannot find unplugged
> device (:08:0b.2)

The above shows the device is not ready/bound yet.


> 2019-11-02T14:14:23.094Z|00071|netdev_dpdk|WARN|Error attaching
> device ':08:0b.2' to DPDK
> 2019-11-02T14:14:23.094Z|00072|netdev|WARN|dpdk-p0: could not set
> configuration (Invalid argument)
> 
> As far as I know, the ring allocation failure that you mentioned
> isn't necessarily a bad thing since it just indicates that DPDK
> reduces something internally (I can't remember what exactly it was)
> to support a high MTU with only 1GB of memory.

True for the memory allocated for DPDK ports. However, there is a
minimum which if it's not there, the mempool allocation will fail.

> I'm wondering now if it might help to change the timing of when
> openvswitch is started after a system reboot to prevent this problem
> as it only occurs after reboot. Do you think that this approach might
> fix the problem?

It will help to get the i40e port working, but that "ring error"
will continue as you see after restarting anyways.

I don't know the other interface types, maybe there is another
interface failing which is not in the log. Do you see any error
reported in 'ovs-vsctl show' after the restart?

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

Re: [ovs-discuss] OVS-bridges Troubleshooting

[Flavio Leitner]

On Wed, 13 Nov 2019 14:02:33 +0200
aeris  wrote:

> Hello,
> 
> I'm new here, so sorry if i missed something or writing to wrong
> maillist
> 
> A bit of foreword -
> 
> We had an installation of ovs in our cloud environment and faced 
> networking issue with vms at random time, but mostly 3-7 minutes
> after reboot(it just stops answering on every request(typical ICMP)
> during time from a few seconds to a few minutes)
> 
> Our internal network for such kind of requests looks like this -
> 
> Physical-switch-->linux
> bond-->ovs-bridge1-->ovs-bridge2-->ovs-bridge3-->VM
> 
> With ovs-tcpdump i found that there is two-sided communication on
> link to VM and between ovs-bridge1 and linux-bond, but only one-sided 
> communication(only icmp-replies/requests depending on from which side 
> ping was issued) on link between ovs-bridge2 and ovs-bridge3 and no 
> packet on any other interface.
> 
> So, actually, my main question is - what instruments do u use when 
> troubleshooting such issues, which I in turn can use in my 
> implementation. And did you faced similar problems in your
> environments?

I see you're using ovs-tcpdump, but you haven't told us if you're using
DPDK or not. Also, how are the bridges connected to each other? veth?
patch ports? and last, what do you have in the flow table?

One thing that you might find useful is ofproto/trace:
https://developers.redhat.com/blog/2016/10/12/tracing-packets-inside-open-vswitch/

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

Re: [ovs-discuss] OVS DPDK: Failed to create memory pool for netdev

[Flavio Leitner]

On Mon, 11 Nov 2019 14:45:13 +
"Tobias Hofmann \(tohofman\) via discuss" 
wrote:

> Hi Flavio,
> 
> to follow up on this: I have just upgraded DPDK to 18.11 and OVS to
> 2.11 and I don't see this issue anymore. Also, I don't observe any
> "ring error" messages although the MTU is still at 9216 and OvS only
> has 1Gb of memory. Do you have an idea which change in DPDK/OvS might
> have resolved it?

There are lots and lots of changes in OVS and DPDK between those
versions and 2.11 is considered stable, so I am glad that you could
update and that it works for you.

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

Re: [ovs-discuss] OVS-bridges Troubleshooting

[Flavio Leitner]

On Thu, 14 Nov 2019 14:38:03 +0200
aeris  wrote:

> about flows - maybe this output would be better -
> 
>   br-int(ovs-bridge3)
>   cookie=0x9f5f4658300163fb, duration=255211.898s, table=71, 
> n_packets=221, n_bytes=9282, 
> priority=95,arp,reg5=0x46,in_port="tapafe5cc97-46",dl_src=b2:ac:73:a2:4e:20,arp_spa=*.*.*.16
>  
> actions=resubmit(,94)
>   cookie=0x9f5f4658300163fb, duration=255211.898s, table=71, 
> n_packets=68274, n_bytes=6379501, 
> priority=65,ip,reg5=0x46,in_port="tapafe5cc97-46",dl_src=b2:ac:73:a2:4e:20,nw_src=*.*.*.16
>  
> actions=ct(table=72,zone=NXM_NX_REG6[0..15])
>   br-ex(ovs-bridge2)
>   cookie=0x539c250217577d59, duration=3197928.791s, table=0, 
> n_packets=717237943, n_bytes=120156920973, 
> priority=4,in_port="phy-br-ex",dl_vlan=3 actions=strip_vlan,NORMAL
>   cookie=0x539c250217577d59, duration=3197935.391s, table=0, 
> n_packets=1919206, n_bytes=278077793, priority=2,in_port="phy-br-ex" 
> actions=drop
>   cookie=0x539c250217577d59, duration=3197935.397s, table=0, 
> n_packets=850526618, n_bytes=408960488324, priority=0 actions=NORMAL
>   br-phy(ovs-bridge1)
>   cookie=0x0, duration=3599826.112s, table=0, n_packets=1574126232, 
> n_bytes=530825513146, priority=0 actions=NORMAL

It looks like you have many tables with many flows, which makes really
hard to follow what is happening over email.

Maybe you can spot the bad packet at a point and save it on a pcap.
Then use ovs-pcap  to convert that packet to a hex string.
Then use that string with ovs-appctl ofproto/trace to simulate what
would happen next?

Go the sources and grep for 'ofproto/trace' in the tests/ subdir and
you will find some practical examples.

HTH,
fbl


> 
> On 11/14/2019 11:58 AM, aeris wrote:
> > We aren't using DPDK now, ports seems to be patch ports as of some 
> > output of ovs-*ctl commands
> >
> > About flow table what I can show ? To be more exact - which out of
> > 300 flows you're interested in (as output of ovs-vsctl dump-flows)?
> >
> > If it is about something about "problematic" VM then -
> > recirc_id(0),in_port(18),ct_state(-trk),eth(src=b2:ac:73:a2:4e:20),eth_type(0x0800),ipv4(src=*.*.*.16,proto=6,frag=no),
> >  
> > packets:46, bytes:3404, used:0.573s, flags:PR., 
> > actions:ct(zone=3),recirc(0xaf01f)
> >
> > recirc_id(0xaf01f),in_port(18),ct_state(-new+est-rel+rpl-inv+trk),ct_zone(0x3),ct_mark(0),eth(src=b2:ac:73:a2:4e:20,dst=64:c3:d6:bb:05:4a),eth_type(0x0800),ipv4(frag=no),
> >  
> > packets:46, bytes:3404, used:0.570s, flags:PR., 
> > actions:push_vlan(vid=500,pcp=0),11
> >
> >
> > Also I've tried to use "ovs-appctl ofproto/trace " and 
> > none of my bridges accepted as an argument(Previously listed them
> > via "ovs-appctl ofproto/list")
> >
> > stderr told me : "ovs-appctl: ovs-vswitchd: server returned an
> > error"
> >
> >
> > On 11/13/2019 3:29 PM, Flavio Leitner wrote:  
> >> On Wed, 13 Nov 2019 14:02:33 +0200
> >> aeris  wrote:
> >>  
> >>> Hello,
> >>>
> >>> I'm new here, so sorry if i missed something or writing to wrong
> >>> maillist
> >>>
> >>> A bit of foreword -
> >>>
> >>> We had an installation of ovs in our cloud environment and faced
> >>> networking issue with vms at random time, but mostly 3-7 minutes
> >>> after reboot(it just stops answering on every request(typical
> >>> ICMP) during time from a few seconds to a few minutes)
> >>>
> >>> Our internal network for such kind of requests looks like this -
> >>>
> >>> Physical-switch-->linux
> >>> bond-->ovs-bridge1-->ovs-bridge2-->ovs-bridge3-->VM
> >>>
> >>> With ovs-tcpdump i found that there is two-sided communication on
> >>> link to VM and between ovs-bridge1 and linux-bond, but only
> >>> one-sided communication(only icmp-replies/requests depending on
> >>> from which side ping was issued) on link between ovs-bridge2 and
> >>> ovs-bridge3 and no packet on any other interface.
> >>>
> >>> So, actually, my main question is - what instruments do u use when
> >>> troubleshooting such issues, which I in turn can use in my
> >>> implementation. And did you faced similar problems in your
> >>> environments?  
> >> I see you're using ovs-tcpdump, but you haven't told us if you're
> >> using DPDK or not. Also, how are the bridges connected to each
> >> other? veth? patch ports? and last, what do you have in the flow
> >> table?
> >>
> >> One thing that you might find useful is ofproto/trace:
> >> https://developers.redhat.com/blog/2016/10/12/tracing-packets-inside-open-vswitch/
> >>  
> >>
> >>
> >> fbl  
> > ___
> > 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 DPDK: Failed to create memory pool for netdev

[Flavio Leitner]

On Mon, 4 Nov 2019 19:12:36 +
"Tobias Hofmann (tohofman)"  wrote:

> Hi Flavio,
> 
> thanks for reaching out.
> 
> The DPDK options used in OvS are:
> 
> other_config:pmd-cpu-mask=0x202
> other_config:dpdk-socket-mem=1024
> other_config:dpdk-init=true
> 
> 
> For the dpdk port, we set:
> 
> type=dpdk
> options:dpdk-devargs=:08:0b.2
> external_ids:unused-drv=i40evf 
> mtu_request=9216

Looks good to me, though the CPU has changed comparing to the log:
2019-11-02T14:51:26.940Z|00010|dpdk|INFO|EAL ARGS: ovs-vswitchd
--socket-mem 1024 -c 0x0001

What I see from the logs is that OvS is trying to add a port, but the
port is not ready yet, so it continues with other things which
also consumes memory. Unfortunately by the time that the i40 port is
ready then there is no memory.

When you restart, the i40 is ready and the memory can be allocated.
However, the ring allocation fails due to lack of memory:

2019-11-02T14:51:27.808Z|00136|dpdk|ERR|RING: Cannot reserve memory
2019-11-02T14:51:27.974Z|00137|dpdk|ERR|RING: Cannot reserve memory

If you reduce the MTU, then the minimum amount of memory required for
the DPDK port reduces drastically, which explains why it works.

Also increasing the total memory to 2G helps because then the minimum
amount for 9216 MTU and the ring seems to be sufficient.

The ring seems to be related to pdump, is that the case?
I don't known of the top of my head.

In summary, looks like 1G is not enough for large MTU and pdump.
HTH,
fbl

> 
> 
> Please let me know if this is what you asked for.
> 
> Thanks
> Tobias
>   
> On 04.11.19, 15:50, "Flavio Leitner"  wrote:
> 
> 
> It would be nice if you share the DPDK options used in OvS.
> 
> On Sat, 2 Nov 2019 15:43:18 +
> "Tobias Hofmann \(tohofman\) via discuss"
>  wrote:
> 
> > Hello community,
> > 
> > My team and I observe a strange behavior on our system with the
> > creation of dpdk ports in OVS. We have a CentOS 7 system with
> > OpenvSwitch and only one single port of type ‘dpdk’ attached to
> > a bridge. The MTU size of the DPDK port is 9216 and the reserved
> > HugePages for OVS are 512 x 2MB-HugePages, e.g. 1GB of total
> > HugePage memory.
> > 
> > Setting everything up works fine, however after I reboot my
> > box, the dpdk port is in error state and I can observe this
> > line in the logs (full logs attached to the mail):
> > 2019-11-02T14:46:16.914Z|00437|netdev_dpdk|ERR|Failed to create
> > memory pool for netdev dpdk-p0, with MTU 9216 on socket 0:
> > Invalid argument
> > 2019-11-02T14:46:16.914Z|00438|dpif_netdev|ERR|Failed to set
> > interface dpdk-p0 new configuration
> > 
> > I figured out that by restarting the openvswitch process, the
> > issue with the port is resolved and it is back in a working
> > state. However, as soon as I reboot the system a second time,
> > the port comes up in error state again. Now, we have also
> > observed a couple of other workarounds that I can’t really
> > explain why they help:
> > 
> >   *   When there is also a VM deployed on the system that is
> > using ports of type ‘dpdkvhostuserclient’, we never see any
> > issues like that. (MTU size of the VM ports is 9216 by the way)
> >   *   When we increase the HugePage memory for OVS to 2GB, we
> > also don’t see any issues.
> >   *   Lowering the MTU size of the ‘dpdk’ type port to 1500 also
> > helps to prevent this issue.
> > 
> > Can anyone explain this?
> > 
> > We’re using the following versions:
> > Openvswitch: 2.9.3
> > DPDK: 17.11.5
> > 
> > Appreciate any help!
> > Tobias  
> 
> 
> 

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

Re: [ovs-discuss] 答复: [ovs-dev] OVS performance issue: why small udp packet pps performance between VMs is highly related with number of ovs ports and number of VMs?

[Flavio Leitner]

On Thu, Feb 13, 2020 at 03:07:33PM +0100, Ilya Maximets wrote:
> On 2/13/20 2:52 PM, Yi Yang (杨燚)-云服务集团 wrote:
> > Thanks Ilya, iperf3 udp should be single direction, source IP address and 
> > destination IP address are two VMs' IP, udp bandwidth will be 0 if they are 
> > wrong, but obviously UDP loss rate is 0, so it isn't the case you're 
> > saying, do we have way to disable MAC learning or MAC broadcast?
> 
> NORMAL action acts like an L2 learning switch.  If you don't
> want to use MAC learning, remove flow with NORMAL action and
> add direct forwarding flow like output:.  But
> I don't think that you want to do that in OpenStack setup.

Also iperf3 establishes the control connection which uses TCP in
both directions. So, in theory, the FDB should be updated.

> > Is NORMAL action or MAC learning slow path process? If so, ovs-vswitchd 
> > daemon should have high cpu utilization.
> 
> It's not a slow path, so there will be no cpu usage by ovs-vswitchd
> userspace process.  To confirm that you're flooding packets, you
> may dump installed datapath flows with the following command:
> 
> ovs-appctl dpctl/dump-flows
> 
> In case of flood, you will see datapath flow with big number of
> output ports like this:
> 
> <...>  actions:,,...

I'd suggest to look at the fdb: ovs-appctl fdb/show 
and port stats to see if there is traffic moving as well.
Maybe it's not your UDP test packet, but another unrelated
traffic in the network.

HTH,
fbl


> 
> > 
> > -----邮件原件-
> > 发件人: Ilya Maximets [mailto:i.maxim...@ovn.org] 
> > 发送时间: 2020年2月13日 21:23
> > 收件人: Flavio Leitner ; Yi Yang (杨燚)-云服务集团 
> > 
> > 抄送: ovs-discuss@openvswitch.org; ovs-...@openvswitch.org; Ilya Maximets 
> > 
> > 主题: Re: [ovs-dev] OVS performance issue: why small udp packet pps 
> > performance between VMs is highly related with number of ovs ports and 
> > number of VMs?
> > 
> > On 2/13/20 12:48 PM, Flavio Leitner wrote:
> >> On Thu, Feb 13, 2020 at 09:18:38AM +, Yi Yang (杨燚)-云服务集团 wrote:
> >>> Hi, all
> >>>
> >>> We find ovs has serious performance issue, we only launch one VM in 
> >>> one compute, and do iperf small udp pps performance test between 
> >>> these two VMs, we can see about 18 pps (packets per second, -l 
> >>> 16), but
> >>>
> >>> 1) if we add 100 veth ports in br-int bridge, respectively, then the pps 
> >>> performance will be about 5 pps.
> >>> 2) If we launch one more VM in every compute node, but don’t run any 
> >>> workload, the pps performance will be about 9 pps. (note, no 
> >>> above veth ports in this test)
> >>> 3) If we launch two more VMs in every compute node (totally 3 VMs 
> >>> every compute nodes), but don’t run any workload , the pps 
> >>> performance will be about 5 pps (note, no above veth ports in 
> >>> this test)
> >>>
> >>> Anybody can help explain why it is so? Is there any known way to 
> >>> optimized this? I really think ovs performance is bad (we can draw 
> >>> such conclusion from our test result at least), I don’t want to 
> >>> defame ovs ☺
> >>>
> >>> BTW, we used ovs kernel datapath and vhost, we can see every port has a 
> >>> vhost kernel thread, it is running with 100% cpu utilization if we run 
> >>> iperf in VM, bu for those idle VMs, the corresponding vhost still has 
> >>> about 30% cpu utilization, I don’t understand why.
> >>>
> >>> In addition, we find udp performance is also very bad for small UDP 
> >>> packet for physical NIC. But it can reach 26 pps for –l 80 which 
> >>> enough covers vxlan header (8 bytes) + inner eth header (14) + ipudp 
> >>> header (28) + 16 = 66, if we consider performance overhead ovs bridge 
> >>> introduces, pps performance between VMs should be able to reach 20 
> >>> pps at least, other VMs and ports shouldn’t have so big hurt against it 
> >>> because they are idle, no any workload there.
> >>
> >> What do you have in the flow table?  It sounds like the traffic is 
> >> being broadcast to all ports. Check the FDB to see if OvS is learning 
> >> the mac addresses.
> >>
> >> It's been a while since I don't run performance tests with kernel 
> >> datapath, but it should be no different than Linux bridge with just 
> >> action NORMAL in the flow table.
> >>
> > 
> > I agree that if your performance heavily depends on the number of ports 
> > than you're most likely just flooding all the packets to all the ports.  
> > Since you're using UDP traffic, please, be sure that you're sending some 
> > packets in backward direction, so OVS and all other switches (if any) will 
> > learn/not forget to which port packets should be sent.  Also, check if your 
> > IP addresses are correct.  If for some reason it's not possible for OVS to 
> > learn MAC addresses correctly, avoid using action:NORMAL.
> > 
> > Best regards, Ilya Maximets.
> > 
> 

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

Re: [ovs-discuss] [ovs-dev] OVS performance issue: why small udp packet pps performance between VMs is highly related with number of ovs ports and number of VMs?

[Flavio Leitner]

On Thu, Feb 13, 2020 at 09:18:38AM +, Yi Yang (杨燚)-云服务集团 wrote:
> Hi, all
> 
> We find ovs has serious performance issue, we only launch one VM in one 
> compute, and do iperf small udp pps performance test between these two VMs, 
> we can see about 18 pps (packets per second, -l 16), but
> 
> 1) if we add 100 veth ports in br-int bridge, respectively, then the pps 
> performance will be about 5 pps.
> 2) If we launch one more VM in every compute node, but don’t run any 
> workload, the pps performance will be about 9 pps. (note, no above veth 
> ports in this test)
> 3) If we launch two more VMs in every compute node (totally 3 VMs every 
> compute nodes), but don’t run any workload , the pps performance will be 
> about 5 pps (note, no above veth ports in this test)
> 
> Anybody can help explain why it is so? Is there any known way to optimized 
> this? I really think ovs performance is bad (we can draw such conclusion from 
> our test result at least), I don’t want to defame ovs ☺
> 
> BTW, we used ovs kernel datapath and vhost, we can see every port has a vhost 
> kernel thread, it is running with 100% cpu utilization if we run iperf in VM, 
> bu for those idle VMs, the corresponding vhost still has about 30% cpu 
> utilization, I don’t understand why.
> 
> In addition, we find udp performance is also very bad for small UDP packet 
> for physical NIC. But it can reach 26 pps for –l 80 which enough covers 
> vxlan header (8 bytes) + inner eth header (14) + ipudp header (28) + 16 = 66, 
> if we consider performance overhead ovs bridge introduces, pps performance 
> between VMs should be able to reach 20 pps at least, other VMs and ports 
> shouldn’t have so big hurt against it because they are idle, no any workload 
> there.

What do you have in the flow table?  It sounds like the traffic is
being broadcast to all ports. Check the FDB to see if OvS is
learning the mac addresses.

It's been a while since I don't run performance tests with kernel
datapath, but it should be no different than Linux bridge with 
just action NORMAL in the flow table.

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

Re: [ovs-discuss] Can we directly output to a patch port like patch-tun?

[Flavio Leitner]

On Mon, Mar 30, 2020 at 11:32:41PM +, Yi Yang (杨�D)-云服务集团 wrote:
> Hi, folks
> 
>  
> 
> We did find Openstack have flood issue in DRV mode, the root cause is
> qrouter stopped MAC learning, this is led by qrouter implementation
> mechanism, we want to add some flows to avoid flood, one way is to add flows
> which can steer the traffic to vxlan port directly, but the issue is vxlan
> port isn’t in br-int, but in br-tun, br-int and br-tun are connected by
> patch port, my question is can we add a flow like this?
> 
>  
> 
> table=60, src_mac=XX.XX.XX.XX.XX.XX, dst_mac=YY.YY.YY.YY.YY.YY,
> actions=set_tunnel(…),output:patch-tun
> 
>  
> 
> Per my previous experience, it seems output to patch port is forbidden, the
> behavior is unknown, can you folks hel confirm if this is ok?

That's the work around some people use to use bond. OvS Bond exposes
the OF Port number of its slave interfaces instead of the bond port.
So, if you want to use bond with OpenFlow, then move the bond port
to a separate bridge (as it is br-tun in your scenario) and use the
patch port OFPort, like your suggestion.

What you can't do is patch-port bridges with different datapath types.

fbl


> If no, can we output to vxlan port in br-tun from br-int? like this, note:
> vxlanZZZ is attached to br-tun, not to br-int.
> 
>  
> 
> table=60, src_mac=XX.XX.XX.XX.XX.XX, dst_mac=YY.YY.YY.YY.YY.YY,
> actions=set_tunnel(…),output:vxlanZZZ
> 

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

Re: [ovs-discuss] OpenvSwitch Message too large

[Flavio Leitner]

Perhaps the interface creating the packet has the wrong MTU?
For instance, a VM is using MTU 1500 but then packets gets
encapsulated?

fbl

On Mon, Oct 19, 2020 at 09:59:13PM +0700, KhacThuan Bk wrote:
>  Hi all,
> 
> I'm using ovs with bonding interface. All interface is using mtu 1500.
> But in ovs-vswitchd.log i saw some log about "Message too long". I cannot
> use ovs-tcpdump to trace message. Any one used face this problem can tell
> my what is problem. I have some info follow this.
> 
> less /var/log/openvswitch/ovs-vswitchd.log
> 2020-10-16T10:26:34.876Z|5804855|dpif_netdev|ERR|error receiving data from
> bond0: Message too long
> 2020-10-16T10:26:34.883Z|5804856|dpif_netdev|ERR|error receiving data from
> bond0: Message too long
> 2020-10-16T10:26:34.888Z|5804857|dpif_netdev|ERR|error receiving data from
> bond0: Message too long
> 2020-10-16T10:26:34.888Z|5804858|dpif_netdev|ERR|error receiving data from
> bond0: Message too long
> 2020-10-16T10:26:34.888Z|5804859|dpif_netdev|ERR|error receiving data from
> bond0: Message too long
> 2020-10-16T10:26:34.936Z|5804860|dpif_netdev|ERR|error receiving data from
> bond0: Message too long
> 2020-10-16T10:26:34.936Z|5804861|dpif_netdev|ERR|error receiving data from
> bond0: Message too long
> 2020-10-16T10:26:34.936Z|5804862|dpif_netdev|ERR|error receiving data from
> bond0: Message too long
> 2020-10-16T10:26:34.947Z|5804863|dpif_netdev|ERR|error receiving data from
> bond0: Message too long
> 2020-10-16T10:26:35.179Z|5804864|dpif_netdev|ERR|error receiving data from
> bond0: Message too long
> 
> 
> [root@host1 ~]# ovs-vsctl show
> a861ee0a-595a-462a-8729-68de6a9026d8
> Manager "ptcp:6640:127.0.0.1"
> is_connected: true
> Bridge br0
> Controller "tcp:127.0.0.1:6633"
> is_connected: true
> fail_mode: secure
> datapath_type: netdev
> Port phy-br0
> Interface phy-br0
> type: patch
> options: {peer=int-br0}
> Port "bond0"
> Interface "bond0"
> Port br0
> Interface br0
> type: internal
> 
> [root@host1 ~]# ip link show bond0
> 10: bond0:  mtu 1500 qdisc
> noqueue state UP mode DEFAULT group default qlen 1000
> link/ether e4:43:4b:ed:33:20 brd ff:ff:ff:ff:ff:ff
> 
> [root@host1 ~]# ovs-vsctl list interface bond0
> _uuid   : 89181c9b-f123-48fb-97ed-3252e39f41ce
> admin_state : up
> bfd : {}
> bfd_status  : {}
> cfm_fault   : []
> cfm_fault_status: []
> cfm_flap_count  : []
> cfm_health  : []
> cfm_mpid: []
> cfm_remote_mpids: []
> cfm_remote_opstate  : []
> duplex  : []
> error   : []
> external_ids: {}
> ifindex : 10
> ingress_policing_burst: 0
> ingress_policing_rate: 0
> lacp_current: []
> link_resets : 0
> link_speed  : []
> link_state  : up
> lldp: {}
> mac : []
> mac_in_use  : "e4:43:4b:ed:33:20"
> mtu : 1500
> mtu_request : 1500
> name: "bond0"
> ofport  : 3
> ofport_request  : []
> options : {}
> other_config: {}
> statistics  : {collisions=0, rx_bytes=428325175126, rx_crc_err=0,
> rx_dropped=3644084274, rx_errors=0, rx_frame_err=0, rx_over_err=0,
> rx_packets=2667110862, tx_bytes=345128207711, tx_dropped=0, tx_errors=0,
> tx_packets=563989135}
> status  : {driver_name=bonding, driver_version="3.7.1",
> firmware_version="2"}
> type: ""
> 
> [root@host2 ~]# ovs-vsctl list interface br0
> _uuid   : c3df3fc1-b78d-464f-af39-1fee5aff12dc
> admin_state : down
> bfd : {}
> bfd_status  : {}
> cfm_fault   : []
> cfm_fault_status: []
> cfm_flap_count  : []
> cfm_health  : []
> cfm_mpid: []
> cfm_remote_mpids: []
> cfm_remote_opstate  : []
> duplex  : full
> error   : []
> external_ids: {}
> ifindex : 24
> ingress_policing_burst: 0
> ingress_policing_rate: 0
> lacp_current: []
> link_resets : 0
> link_speed  : 1000
> link_state  : down
> lldp: {}
> mac : []
> mac_in_use  : "e4:43:4b:ec:c5:60"
> mtu : 1500
> mtu_request : []
> name: br0
> ofport  : 65534
> ofport_request  : []
> options : {}
> other_config: {}
> statistics  : {collisions=0, rx_bytes=0, rx_crc_err=0,
> rx_dropped=0, rx_errors=0, rx_frame_err=0, rx_over_err=0, rx_packets=0,
> tx_bytes=0, tx_dropped=1000184, tx_errors=0, tx_packets=0}
> status  : {driver_name=tun, driver_version="1.6",
> firmware_version=""}
> type: internal

> ___
> discuss mailing list
> 

Re: [ovs-discuss] [ovs-dev] Question about supporting the OVS out-of-tree kernel drivers

[Flavio Leitner]

On Sun, Nov 29, 2020 at 02:30:29AM +0100, Ilya Maximets wrote:
> On 11/12/20 6:04 PM, Gregory Rose wrote:
> > 
> > 
> > On 11/12/2020 5:10 AM, Mark Gray wrote:
> >> On 30/10/2020 18:32, Gregory Rose wrote:
> >>>
> >>> The question is whether there is any interest in continuing to support
> >>> the OVS out-of-tree (OOT) kernel driver or should we deprecate it?  The
> >>> latest kernel support for the OOT driver is up to 5.8.x  There seems to
> >>> be little interest that I can tell in using the OOT driver.  The main
> >>> distros all include the kernel built-in OVS driver and those drivers
> >>> generally seem to support all the primary features required by user space.
> >>>
> >>> Most of the energy on this list seems to be directed toward DPDK and OVN
> >>> and it doesn't seem to me that either of those require the OOT driver.
> >>> If there's no one actually using the OOT driver I suggest we deprecate
> >>> it and save time and energy on keeping it up to date.
> >>>
> >>> Opinions, thoughts, comments?
> >>>
> >>
> >> I think it is good to raise this question. Thanks.
> >>
> >> It would certainly simplify development of kernel features and avoid the
> >> type of issue that I had recently with a patch in the OOT tree but not
> >> upstream. As I don't know who uses OOT, I can't comment beyond that.
> > 
> > I'm knee deep in some work at my day job but when I get a
> > chance I'm going to send a patch for the faq, NEWS, etc. and request
> > that we deprecate the OOT driver and end support for newer kernels
> > at the current 5.8.  After that we'll only take bug fixes.
> > 
> > I don't really believe there are any consumers for the OOT driver
> > on this list anymore.  Certainly the lack of response to this
> > question indicates that.
> 
> CC: ovs-discuss
> 
> Thanks for raising this question.
> 
> As far as the topic goes, the only thing that might get people to use
> the OOT module with kernels higher than 5.8 is SST or LISP support.
> On the other hand, there were reasons to reject patches to support these
> protocols in the mainline kernel.  And I have no idea if anyone is actually
> using them.  I never used them and I'm not even sure if they actually work
> taking into account that we have only 2 system tests for them that doesn't
> really check much.
> 
> Maybe we could also raise the question during the conference to get more
> attention.  I'd like to add a reference into my "community updates"
> presentation.
> 
> I know that it takes a lot of time to support OOT kernel module and it
> doesn't seem worth the effort.  I'd vote for deprecation and eventual
> removal.  Sending patches is a good idea, with them we could move forward
> if no strong objections will appear.  And thanks for all the work you did
> supporting kernel module all that time!

Since the conference already happened, have you decided something?

I suggest to follow "Feature Deprecation Guidelines" section in
Documentation/internals/contributing/submitting-patches.rst with
the addition of warning when building that code for extra
visibility.

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

Re: [ovs-discuss] Moving of the primary #openvswitch channel to irc.libera.chat ?

[Flavio Leitner]

On Wed, May 19, 2021 at 01:22:58PM -0700, Ben Pfaff wrote:
> On Wed, May 19, 2021 at 10:03:57PM +0200, Ilya Maximets wrote:
> > Hi.
> > 
> > Taking into account some very unhealthy things that happened recently
> > with FreeNode network and resigning of lots of its stuff [1], we
> > probably need to discuss if Open vSwitch project wants to change the
> > IRC server for a primary #openvswitch channel.  User's data is the
> > main concern, IIUC, as it's unclear what the new management will
> > do with the network.
> > 
> > The main alternative now seems to be the Libera.Chat [2] where most of
> > the former FreeNode stuff.
> > 
> > Some projects already announced [3][4] movement to Libera.Chat.  Others
> > are discussing the possibility [5].
> > 
> > So, I think, it make sense to discuss the future of #openvswitch
> > channel too.  Any thoughts?
> > 
> > Will we have an OVN meeting on a different server tomorrow?
> 
> Thanks for sending such a detailed message (with footnotes!).
> I think I support the move.  I have already registered the #openvswitch
> channel on libera.chat (and copied the topic across).

Great! Thanks.


> I'm going to log in on both servers tomorrow but I suggest that we
> transition to libera.chat after tomorrow's meeting, since this is pretty
> short notice and I think that most of us (including me) are only light
> users of IRC.
> 
> Also, I suspect that the infrastructure for recording meetings has not
> yet moved to libera.chat.  (I did notice that the 'openstack' user just
> dropped out of #openvswitch.  I think that's the bot that did the
> meeting recordings.  So maybe that infastructure is moving across right
> as I write.)

When things are ported, please change freenode's #openvswitch topic
to say that we are moving to the new network.

Usually the 'topic' is displayed when someone joins the channel, so
it could help users to find out about the change.

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

[ovs-discuss] [ADVISORY] CVE-2020-35498: Packet parsing vulnerability.

[Flavio Leitner]

Description
===

Multiple versions of Open vSwitch are vulnerable to potential problems
like denial of service attacks, in which crafted network packets could
cause the packet lookup to ignore network header fields from layers 3
and 4.

Both kernel and userspace datapaths are affected, including DPDK enabled
Open vSwitch (OVS-DPDK) as an example of the latter.

The crafted network packet is an ordinary IPv4 or IPv6 packet with
Ethernet padding length above 255 bytes. This causes the packet sanity
check to abort parsing header fields after layer 2.

When that situation happens, the classifier will use an unexpected set
of header fields. This could cause the packet lookup to either match
on unintended flows or return the default table miss action 'drop'.

As a consequence, the datapath can be instructed to match on an
incorrect range of packets with an action to drop them, for example.
Further legit traffic could hit the cached flow preventing it to
expire extending the situation.

The Common Vulnerabilities and Exposures project (cve.mitre.org)
assigned the identifier CVE-2020-35498 to this issue.

Mitigation
==

For any version of Open vSwitch, preventing such packets to be
received by Open vSwitch or removing the excess of padding before
they are received by Open vSwitch mitigates the vulnerability. We
do not recommend attempting to mitigate the vulnerability this way
because of the following difficulties:

 - Open vSwitch obtains packets before the iptables or nftables
   host firewall, so iptables or nftables on the Open vSwitch host
   cannot ordinarily block the vulnerability.

 - If Open vSwitch is configured to support tunnels, such packets
   encapsulated within tunnels must also be prevented from reaching
   the host.

 - If Open vSwitch runs on a hypervisor, such packets from VMs can
   also trigger the vulnerability.


Fix
===

Patches to fix these vulnerabilities in Open vSwitch 2.5.x and newer are
applied to the various appropriate branches:

* master
https://github.com/openvswitch/ovs/commit/79349cbab0b2a755140eedb91833ad2760520a83

* 2.15
https://github.com/openvswitch/ovs/commit/0625dc79aec73b966f206e55655a2816696246d0

* 2.14
https://github.com/openvswitch/ovs/commit/59b588604b89e85b463984ba08a99badb4fcba15

* 2.13
https://github.com/openvswitch/ovs/commit/3512fb512c76a1f08eba4005aa2eb69160d0840e

* 2.12
https://github.com/openvswitch/ovs/commit/53c1b8b166f3dd217bc391d707885f789e9ecc49

* 2.11
https://github.com/openvswitch/ovs/commit/abd7a457652e6734902720fe6a5dddb3fc0d1e3b

* 2.10
https://github.com/openvswitch/ovs/commit/79cec1a736b91548ec882d840986a11affda1068

* 2.9
https://github.com/openvswitch/ovs/commit/48ceca0446b1c2c2c03e7551048c5b19ed23cc97

* 2.8
https://github.com/openvswitch/ovs/commit/35c280072c1c3ed58202745b7d27fbbd0736999b

* 2.7
https://github.com/openvswitch/ovs/commit/ad0d22f6435b43ecfc30c0e877d490d36721f200

* 2.6
https://github.com/openvswitch/ovs/commit/673c08eee8c8d4f2999ddd31524de7ff0f72b559

* 2.5
https://github.com/openvswitch/ovs/commit/354e7d860e444fd1472541b0fdc3b8678aa74828


Recommendation
==

We recommend that users of Open vSwitch apply the included patch, or
upgrade to a known patched version of Open vSwitch.  These include:

* 2.14.2
* 2.13.3
* 2.12.3
* 2.11.6
* 2.10.7
* 2.9.9
* 2.8.11
* 2.7.13
* 2.6.10
* 2.5.12


Acknowledgments
===

The Open vSwitch team wishes to thank the reporter:

Joakim Hindersson 






OpenPGP_signature
Description: OpenPGP digital signature
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] release schedule change proposal

[Flavio Leitner]

Thanks Kevin for bringing this up.
See below.

On Mon, Nov 15, 2021 at 1:06 PM Kevin Traynor  wrote:

> On 15/11/2021 14:58, Thomas Monjalon wrote:
> > For the last 5 years, DPDK was doing 4 releases per year,
> > in February, May, August and November (the LTS one):
> >   .02   .05   .08   .11 (LTS)
> >
> > This schedule has multiple issues:
> >   - clash with China's Spring Festival
> >   - too many rushes, impacting maintainers & testers
> >   - not much buffer, impacting proposal period
> >
> > I propose to switch to a new schedule with 3 releases per year:
> >   .03  .07  .11 (LTS)
> >
> > New LTS branch would start at the same time of the year as before.
> > There would be one less intermediate release during spring/summer:
> > .05 and .08 intermediate releases would become a single .07.
> > I think it has almost no impact for the users.
> > This change could be done starting next year.
> >
> > In details, this is how we could extend some milestones:
> >
> >   ideal schedule so far (in 13 weeks):
> >   proposal deadline: 4
> >   rc1 - API freeze: 5
> >   rc2 - PMD features freeze: 2
> >   rc3 - app features freeze: 1
> >   rc4 - last chance to fix: 1
> >   release: 0
> >
> >   proposed schedule (in 17 weeks):
> >   proposal deadline: 4
> >   rc1 - API freeze: 7
> >   rc2 - PMD features freeze: 3
> >   rc3 - app features freeze: 1
> >   rc4 - more fixes: 1
> >   rc5 - last chance buffer: 1
> >   release: 0
> >
> > Opinions?
> >
> >
>
> Someone else might comment if they spot something, but to me looks ok
> for RH distro and OVS project.
>

That is my impression as well.


>
> RH distro is also using DPDK .11 who's release date is not changing.
> (+cc Timothy/Flavio)
>

My concern is if patches would get delayed to be merged because of this
change, but I don't think that will be the case.


> For OVS project, it only integrates DPDK .11 release too and aims to do
> that by EOY to make the next OVS release. DPDK stable releases are
> integrated into older OVS branches when available. I don't think older
> OVS branch releases have a strict release schedule and having the latest
> stable DPDK release is not a blocker anyway. (+cc Ilya/Ian/ovs-discuss)
>

I agree.

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

Re: [ovs-discuss] OVS - QEMU unable to create vhostuserclient socket at /var/run/openvswitch

[Flavio Leitner via discuss]

Do you have SELinux enabled? Sounds like the policies are not
updated.
fbl

On Thu, May 16, 2019 at 04:16:04PM +, Joan Vidal wrote:
> Hi Ian,
> 
> Upgraded QEMU version to 2.10.0(qemu-kvm-ev-2.10.0-21.el7_5.7.1)
> Changed /etc/libvirt/qemu.conf
> user = "root"
> group = "root" 
> 
> And added following lines to guest XML definition:
> 
> 
>   
> 
> 
> 
> 
> 
> 
> 
>   
> 
> 
>   
> 
> 
> 
>   
>   
>   
>   
>   
> 
>   
>function='0x0'/>
> 
> 
>   
>   
>   
>   
>   
> 
>   
>function='0x0'/>
> 
> 
> 
> Still getting same error:
> 
> 2019-05-16T16:07:27.921191Z qemu-kvm: -chardev 
> socket,id=charnet2,path=/var/run/openvswitch/vhost0,server: Failed to bind 
> socket to /var/run/openvswitch/vhost0: Permission denied
> 2019-05-16 16:07:28.140+: shutting down, reason=failed
> 
> 
>  *Joan Vidal*
>  
>  *OmniAccess*
> 
> -Mensaje original-
> De: Ian Stokes  
> Enviado el: 16 May 2019 16:33
> Para: Joan Vidal ; ovs-discuss@openvswitch.org
> Asunto: Re: [ovs-discuss] OVS - QEMU unable to create vhostuserclient socket 
> at /var/run/openvswitch
> 
> On 5/16/2019 3:04 PM, Joan Vidal wrote:
> > Hi,
> > 
> > I'm trying to use OVS-DPDK  vhostuserclient ports with a qemu guest on 
> > a CentOS host.
> > 
> > QEMU guest fails to start with the following error:
> > 
> > error: internal error: process exited while connecting to monitor: 
> > 2019-05-16T13:15:27.481680Z qemu-kvm: -chardev
> > socket,id=charnet2,path=/var/run/openvswitch/vhost0,server: Failed to 
> > bind socket: Permission denied 2019-05-16T13:15:27.482078Z qemu-kvm: 
> > -chardev
> > socket,id=charnet2,path=/var/run/openvswitch/vhost0,server: chardev: 
> > opening backend "socket" failed
> > 
> > 
> > Seems to be an issue with qemu-kvm permission to create the sockets in 
> > /var/run/openvswitch Followed this article 
> > https://www.redhat.com/en/blog/ovs-dpdk-migrating-vhostuser-socket-mod
> > e-red-hat-openstack
> > 
> > But is showing same error. Even running qemu-kvm and openvswitch with 
> > root is still returning Permission denied.
> > 
> > 
> > This is the system configuration:
> > 
> > --
> > Software versions:
> > 
> > (Host) CentOS Linux release 7.6.1810 (Core)
> > (Guest) CentOS Linux release 7.4.1708 (Core) QEMU emulator version 
> > 1.5.3 (qemu-kvm-1.5.3-160.el7_6.1)
> 
> The minimum QEMU version recommended for use with vhostuserclient is QEMU 2.7 
> (See OVS Documentation below).
> 
> http://docs.openvswitch.org/en/latest/topics/dpdk/vhost-user/#vhost-user-vs-vhost-user-client
> 
> Do you see the same issue when using QEMU 2.7?
> 
> Also from below it looks like you are using libvirt to configure QEMU?
> 
> If so have you followed the steps outlined in the link below
> 
> http://docs.openvswitch.org/en/latest/topics/dpdk/vhost-user/#adding-vhost-user-ports-to-the-guest-libvirt
> 
> Ian
> 
> > ovs-vswitchd (Open vSwitch) 2.11.1
> > DPDK 18.11.0
> > 
> > 
> > --
> > OVS configuration
> > 
> > 
> > #ovs-vsctl show
> > 462375d2-8f6a-4a72-ad49-af8c00720da9
> >      Bridge br-subscriber
> >          Port br-subscriber
> >              Interface br-subscriber
> >                  type: internal
> >          Port "ens1f0"
> >              Interface "ens1f0"
> >                  type: dpdk
> >                  options: {dpdk-devargs=":81:00.0"}
> >          Port "vhost0"
> >              Interface "vhost0"
> >                  type: dpdkvhostuserclient
> >                  options: 
> > {vhost-server-path="/var/run/openvswitch/vhost0"}
> >      Bridge br-internet
> >          Port br-internet
> >              Interface br-internet
> >                  type: internal
> >          Port "vhost1"
> >              Interface "vhost1"
> >                  type: dpdkvhostuserclient
> >                  options: 
> > {vhost-server-path="/var/run/openvswitch/vhost1"}
> >          Port "ens1f1"
> >              Interface "ens1f1"
> >                  type: dpdk
> >                  options: {dpdk-devargs=":81:00.1"}
> >      ovs_version: "2.11.1"
> > 
> > #ovs-vsctl get Open_vSwitch . other_config {dpdk-init="true", 
> > dpdk-socket-mem="0,2048", pmd-cpu-mask="0x02000200"}
> > 
> > 
> > #cat /etc/sysconfig/openvswitch
> > OPTIONS=""
> > OVS_USER_ID="openvswitch:hugetlbfs"
> > 
> > 
> > # ls -la /var/run/openvswitch/
> > total 12
> > drwxrwsr-x.  3 openvswitch hugetlbfs 260 May 16 12:00 .
> > drwxr-xr-x. 29 root        root      920 May 16 12:14 ..
> > srwxr-x---.  1 openvswitch hugetlbfs   0 May 16 12:00 br-internet.mgmt 
> > srwxr-x---.  1 openvswitch hugetlbfs   0 May 16 12:00 
> > br-internet.snoop srwxr-x---.  1 openvswitch hugetlbfs   0 May 16 
> > 12:00 br-subscriber.mgmt srwxr-x---.  1 openvswitch hugetlbfs   0 May 
> > 16 12:00 br-subscriber.snoop srwxr-x---.  1 openvswitch hugetlbfs   0 
> > May 16 12:00 db.sock drwx--.  3 openvswitch 

Re: [ovs-discuss] Restarting network kills ovs-vswitchd (and network)... ?

[Flavio Leitner via discuss]

On Thu, May 16, 2019 at 09:34:28AM +, SCHAER Frederic wrote:
> Hi,
> I'm facing an issue with openvswitch, which I think is new (not even sure).
> here is the description :
> 
> * What you did that make the problem appear.
> 
> I am configuring openstack (compute, network) nodes using OVS networks for 
> main interfaces and RHEL network scripts, basically using openvswitch to 
> create bridges, set the bridges IPs, and include the real Ethernet devices in 
> the bridges.
> On a compute machine (not in production, so not using 3 or more interfaces), 
> I have for instance brflat -> em1.
> Brflat has multiple IPs defined using IPADDR1, IPADDR2, etc..
> Now : at boot, machine has network. Bur if I ever change anything in network 
> scripts and issue either a network restart, an ifup or an ifdown : network 
> breaks and connectivity is lost.
> 
> Also, on network restarts, I'm getting these logs in the network journal :
> May 16 10:26:41 cloud1 ovs-vsctl[1766678]: ovs|1|vsctl|INFO|Called as 
> ovs-vsctl -t 10 -- --may-exist add-br brflat
> May 16 10:26:51 cloud1 ovs-vsctl[1766678]: 
> ovs|2|fatal_signal|WARN|terminating with signal 14 (Alarm clock)
> May 16 10:26:51 cloud1 network[1766482]: Bringing up interface brflat:  
> 2019-05-16T08:26:51Z|2|fatal_signal|WARN|terminating with signal 14 
> (Alarm clock)
> 
> * What you expected to happen.
> 
> On network restart... to get back a working network. Not be forced to log in 
> using ipmi console and fix network manually.
> 
> * What actually happened.
> 
> What actually happens is that on ifup/ifdown/network restart, the 
> ovs-vswitchd daemon stops working. According to systemctl, it is actually 
> exiting with code 0.
> If I do a ifdown on one interface, then ovs-vswitchd is down.
> After ovs-vswitchd restart, I then can ifup that interface : network is still 
> down (no ping, nothing).
> Ovs-vswitchd is again dead/stopped/exited 0.
> Then : manually starting ovs-vswitchd restores connectivity.
> 
> Please also include the following information:
> * The Open vSwitch version number (as output by ovs-vswitchd --version).
> ovs-vswitchd (Open vSwitch) 2.10.1

Sounds like OVS is crashing. Please check 'dmesg' if you see
segmentation fault messages in there. Or the journal logs.
Or the systemd service status.

If it is, then the next step is to enable coredumps to grab one
core. Then install openvswitch-debuginfo package to see the
stack trace.

You're right that ifdown should not put the service down.

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

Re: [ovs-discuss] OVS - QEMU unable to create vhostuserclient socket at /var/run/openvswitch

[Flavio Leitner via discuss]

On Fri, May 17, 2019 at 09:13:08AM +, Joan Vidal wrote:
> Hi Flavio,
> 
> SELinux is disabled.

Could you add the port to OVS and tell us the file ownership
and perms of the socket? (/var/run/openvswitch/vhost0)

The same for /var/run/openvswitch directory.

One quick test is to use /tmp instead of /var/run/openvswitch.

fbl
> 
> 
> Joan
> 
> ____________
> De: Flavio Leitner 
> Enviado: viernes, 17 de mayo de 2019 10:35
> Para: Joan Vidal
> Cc: Ian Stokes; ovs-discuss@openvswitch.org
> Asunto: Re: [ovs-discuss] OVS - QEMU unable to create vhostuserclient socket 
> at /var/run/openvswitch
> 
> 
> Do you have SELinux enabled? Sounds like the policies are not
> updated.
> fbl
> 
> On Thu, May 16, 2019 at 04:16:04PM +, Joan Vidal wrote:
> > Hi Ian,
> >
> > Upgraded QEMU version to 2.10.0(qemu-kvm-ev-2.10.0-21.el7_5.7.1)
> > Changed /etc/libvirt/qemu.conf
> > user = "root"
> > group = "root"
> >
> > And added following lines to guest XML definition:
> >
> >
> >   
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> >   
> >
> > 
> >> memAccess='shared'/>
> > 
> >
> > 
> >   
> >   
> >   
> >   
> >   
> > 
> >   
> >> function='0x0'/>
> > 
> > 
> >   
> >   
> >   
> >   
> >   
> > 
> >   
> >> function='0x0'/>
> > 
> >
> >
> > Still getting same error:
> >
> > 2019-05-16T16:07:27.921191Z qemu-kvm: -chardev 
> > socket,id=charnet2,path=/var/run/openvswitch/vhost0,server: Failed to bind 
> > socket to /var/run/openvswitch/vhost0: Permission denied
> > 2019-05-16 16:07:28.140+: shutting down, reason=failed
> >
> >
> >  *Joan Vidal*
> >
> >  *OmniAccess*
> >
> > -Mensaje original-
> > De: Ian Stokes 
> > Enviado el: 16 May 2019 16:33
> > Para: Joan Vidal ; ovs-discuss@openvswitch.org
> > Asunto: Re: [ovs-discuss] OVS - QEMU unable to create vhostuserclient 
> > socket at /var/run/openvswitch
> >
> > On 5/16/2019 3:04 PM, Joan Vidal wrote:
> > > Hi,
> > >
> > > I'm trying to use OVS-DPDK  vhostuserclient ports with a qemu guest on
> > > a CentOS host.
> > >
> > > QEMU guest fails to start with the following error:
> > >
> > > error: internal error: process exited while connecting to monitor:
> > > 2019-05-16T13:15:27.481680Z qemu-kvm: -chardev
> > > socket,id=charnet2,path=/var/run/openvswitch/vhost0,server: Failed to
> > > bind socket: Permission denied 2019-05-16T13:15:27.482078Z qemu-kvm:
> > > -chardev
> > > socket,id=charnet2,path=/var/run/openvswitch/vhost0,server: chardev:
> > > opening backend "socket" failed
> > >
> > >
> > > Seems to be an issue with qemu-kvm permission to create the sockets in
> > > /var/run/openvswitch Followed this article
> > > https://www.redhat.com/en/blog/ovs-dpdk-migrating-vhostuser-socket-mod
> > > e-red-hat-openstack
> > >
> > > But is showing same error. Even running qemu-kvm and openvswitch with
> > > root is still returning Permission denied.
> > >
> > >
> > > This is the system configuration:
> > >
> > > --
> > > Software versions:
> > >
> > > (Host) CentOS Linux release 7.6.1810 (Core)
> > > (Guest) CentOS Linux release 7.4.1708 (Core) QEMU emulator version
> > > 1.5.3 (qemu-kvm-1.5.3-160.el7_6.1)
> >
> > The minimum QEMU version recommended for use with vhostuserclient is QEMU 
> > 2.7 (See OVS Documentation below).
> >
> > http://docs.openvswitch.org/en/latest/topics/dpdk/vhost-user/#vhost-user-vs-vhost-user-client
> >
> > Do you see the same issue when using QEMU 2.7?
> >
> > Also from below it looks like you are using libvirt to configure QEMU?
> >
> > If so have you followed the steps outlined in the link below
> >
> > http://docs.openvswitch.org/en/latest/topics/dpdk/vhost-user/#adding-vhost-user-ports-to-the-guest-libvirt
> >
> > Ian
> >
> > > ovs-vswitchd (Open vSwitch) 2.11.1
> > > DPDK 18.11.0
> > >
> > >
> > > --
> > > OVS configuration
> > >
> > >
> > > #ovs-vsctl show
> > > 

Re: [ovs-discuss] OVS - QEMU unable to create vhostuserclient socket at /var/run/openvswitch

[Flavio Leitner via discuss]

On Fri, May 17, 2019 at 06:39:26AM -0300, Flavio Leitner via discuss wrote:
> On Fri, May 17, 2019 at 09:13:08AM +, Joan Vidal wrote:
> > Hi Flavio,
> > 
> > SELinux is disabled.
> 
> Could you add the port to OVS and tell us the file ownership
> and perms of the socket? (/var/run/openvswitch/vhost0)
> 
> The same for /var/run/openvswitch directory.
> 
> One quick test is to use /tmp instead of /var/run/openvswitch.

Sorry the quick reply, I think /var/run/openvswitch is owned by
root.root and then ovs cannot open the socket there.

On my system:
ls -lad /var/run/openvswitch/
drwxr-xr-x 2 openvswitch hugetlbfs 200 May 14 09:56 /var/run/openvswitch/


Then OVS and QEMU runs as gid hugetlbfs.
fbl

> 
> fbl
> > 
> > 
> > Joan
> > 
> > 
> > De: Flavio Leitner 
> > Enviado: viernes, 17 de mayo de 2019 10:35
> > Para: Joan Vidal
> > Cc: Ian Stokes; ovs-discuss@openvswitch.org
> > Asunto: Re: [ovs-discuss] OVS - QEMU unable to create vhostuserclient 
> > socket at /var/run/openvswitch
> > 
> > 
> > Do you have SELinux enabled? Sounds like the policies are not
> > updated.
> > fbl
> > 
> > On Thu, May 16, 2019 at 04:16:04PM +, Joan Vidal wrote:
> > > Hi Ian,
> > >
> > > Upgraded QEMU version to 2.10.0(qemu-kvm-ev-2.10.0-21.el7_5.7.1)
> > > Changed /etc/libvirt/qemu.conf
> > > user = "root"
> > > group = "root"
> > >
> > > And added following lines to guest XML definition:
> > >
> > >
> > >   
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > >   
> > >
> > > 
> > >> > memAccess='shared'/>
> > > 
> > >
> > > 
> > >   
> > >> > mode='server'/>
> > >   
> > >   
> > >   
> > > 
> > >   
> > >> > function='0x0'/>
> > > 
> > > 
> > >   
> > >> > mode='server'/>
> > >   
> > >   
> > >   
> > > 
> > >   
> > >> > function='0x0'/>
> > > 
> > >
> > >
> > > Still getting same error:
> > >
> > > 2019-05-16T16:07:27.921191Z qemu-kvm: -chardev 
> > > socket,id=charnet2,path=/var/run/openvswitch/vhost0,server: Failed to 
> > > bind socket to /var/run/openvswitch/vhost0: Permission denied
> > > 2019-05-16 16:07:28.140+: shutting down, reason=failed
> > >
> > >
> > >  *Joan Vidal*
> > >
> > >  *OmniAccess*
> > >
> > > -Mensaje original-
> > > De: Ian Stokes 
> > > Enviado el: 16 May 2019 16:33
> > > Para: Joan Vidal ; ovs-discuss@openvswitch.org
> > > Asunto: Re: [ovs-discuss] OVS - QEMU unable to create vhostuserclient 
> > > socket at /var/run/openvswitch
> > >
> > > On 5/16/2019 3:04 PM, Joan Vidal wrote:
> > > > Hi,
> > > >
> > > > I'm trying to use OVS-DPDK  vhostuserclient ports with a qemu guest on
> > > > a CentOS host.
> > > >
> > > > QEMU guest fails to start with the following error:
> > > >
> > > > error: internal error: process exited while connecting to monitor:
> > > > 2019-05-16T13:15:27.481680Z qemu-kvm: -chardev
> > > > socket,id=charnet2,path=/var/run/openvswitch/vhost0,server: Failed to
> > > > bind socket: Permission denied 2019-05-16T13:15:27.482078Z qemu-kvm:
> > > > -chardev
> > > > socket,id=charnet2,path=/var/run/openvswitch/vhost0,server: chardev:
> > > > opening backend "socket" failed
> > > >
> > > >
> > > > Seems to be an issue with qemu-kvm permission to create the sockets in
> > > > /var/run/openvswitch Followed this article
> > > > https://www.redhat.com/en/blog/ovs-dpdk-migrating-vhostuser-socket-mod
> > > > e-red-hat-openstack
> > > >
> > > > But is showing same error. Even running qemu-kvm and openvswitch with
> > > > root is still returning Permission denied.
> > > >
> > > >
> > > > This is the system configuration:
> > > >
> > > > --
> > > > Software versions:
> > > >
> > > > (Host

Re: [ovs-discuss] Restarting network kills ovs-vswitchd (and network)... ?

[Flavio Leitner via discuss]

++
> [pid 175227] +++ killed by SIGABRT +++
> [pid 175226] +++ killed by SIGABRT +++
> [pid 175225] +++ killed by SIGABRT +++
> [pid 175224] +++ killed by SIGABRT +++
> [pid 175223] +++ killed by SIGABRT +++
> [pid 175222] +++ killed by SIGABRT +++
> [pid 175085] +++ killed by SIGABRT +++
> +++ killed by SIGABRT +++
> 
> 
> Regards
> 
> > -Message d'origine-
> > De : Flavio Leitner 
> > Envoyé : vendredi 17 mai 2019 10:29
> > À : SCHAER Frederic 
> > Cc : b...@openvswitch.org
> > Objet : Re: [ovs-discuss] Restarting network kills ovs-vswitchd (and
> > network)... ?
> > 
> > On Thu, May 16, 2019 at 09:34:28AM +, SCHAER Frederic wrote:
> > > Hi,
> > > I'm facing an issue with openvswitch, which I think is new (not even 
> > > sure).
> > > here is the description :
> > >
> > > * What you did that make the problem appear.
> > >
> > > I am configuring openstack (compute, network) nodes using OVS networks
> > for main interfaces and RHEL network scripts, basically using openvswitch to
> > create bridges, set the bridges IPs, and include the real Ethernet devices 
> > in
> > the bridges.
> > > On a compute machine (not in production, so not using 3 or more
> > interfaces), I have for instance brflat -> em1.
> > > Brflat has multiple IPs defined using IPADDR1, IPADDR2, etc..
> > > Now : at boot, machine has network. Bur if I ever change anything in
> > network scripts and issue either a network restart, an ifup or an ifdown :
> > network breaks and connectivity is lost.
> > >
> > > Also, on network restarts, I'm getting these logs in the network journal :
> > > May 16 10:26:41 cloud1 ovs-vsctl[1766678]: ovs|1|vsctl|INFO|Called
> > > as ovs-vsctl -t 10 -- --may-exist add-br brflat May 16 10:26:51 cloud1
> > > ovs-vsctl[1766678]: ovs|2|fatal_signal|WARN|terminating with
> > > signal 14 (Alarm clock) May 16 10:26:51 cloud1 network[1766482]:
> > > Bringing up interface brflat:
> > > 2019-05-16T08:26:51Z|2|fatal_signal|WARN|terminating with signal
> > > 14 (Alarm clock)
> > >
> > > * What you expected to happen.
> > >
> > > On network restart... to get back a working network. Not be forced to log 
> > > in
> > using ipmi console and fix network manually.
> > >
> > > * What actually happened.
> > >
> > > What actually happens is that on ifup/ifdown/network restart, the ovs-
> > vswitchd daemon stops working. According to systemctl, it is actually 
> > exiting
> > with code 0.
> > > If I do a ifdown on one interface, then ovs-vswitchd is down.
> > > After ovs-vswitchd restart, I then can ifup that interface : network is 
> > > still
> > down (no ping, nothing).
> > > Ovs-vswitchd is again dead/stopped/exited 0.
> > > Then : manually starting ovs-vswitchd restores connectivity.
> > >
> > > Please also include the following information:
> > > * The Open vSwitch version number (as output by ovs-vswitchd --version).
> > > ovs-vswitchd (Open vSwitch) 2.10.1
> > 
> > Sounds like OVS is crashing. Please check 'dmesg' if you see segmentation
> > fault messages in there. Or the journal logs.
> > Or the systemd service status.
> > 
> > If it is, then the next step is to enable coredumps to grab one core. Then
> > install openvswitch-debuginfo package to see the stack trace.
> > 
> > You're right that ifdown should not put the service down.
> > 
> > fbl
> ___
> 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] VxLAN in Userspace

[Flavio Leitner via discuss]

On Thu, Jun 13, 2019 at 10:58:21PM -0400, Vasu Dasari wrote:
> Flavio,
> 
> tnl_neigh_cache_flush(), flushes entire tunnel ARP table. When a bridge is
> removed, ARP entries learnt on that bridge alone have to be removed.
> Entries from other bridges have to be in tact.
> 
> I am thinking of doing the following:
> 
> 1. Write a new API in lib/tnl-neigh-cache.c: tnl_neigh_flush(const char*
> br_name) which purges all neighbor entries on bridge br_name.

That's better, indeed.


> 2. From ofproto/ofproto-dpif-xlate.c: xlate_xbridge_remove() invoke the
> function tnl_neigh_flush () to flush the entries.
> 
> til_neigh_xxx() functions are getting called from ofproto-dpif-xlate.c, and
> hence thinking that xlate_xbridge_remove() is a right place to do the job.
> 
> What do you think?

The device with the IP address can be any regular interface, so
do you think it would work if you remove a device that is out of
OVS? 

fbl

> 
> -Vasu
> 
> 
> On Thu, Jun 13, 2019 at 7:27 PM Vasu Dasari  wrote:
> 
> > Yes Flavio. Looking at code to fix this. Will send fix for review soon.
> >
> > Vasu
> >
> > > On Jun 13, 2019, at 7:15 PM, Flavio Leitner  wrote:
> > >
> > >> On Wed, Jun 12, 2019 at 07:18:27PM -0400, Vasu Dasari wrote:
> > >> Thanks Ben. Meanwhile I think I found an bug in OVS 2.9.0 with stale ARP
> > >> entries after a bridge is deleted.
> > >>
> > >> I ran my tunneling experiment successfully. Used mininet to simulate the
> > >> environment. After quitting the mininet, switch s1 is deleted. But, I
> > still
> > >> see the ARP entries in OVS.
> > >
> > > Looks like when route_table_valid is false we also need to
> > > call tnl_neigh_cache_flush() otherwise you will need to wait
> > > the ARP entry in the cache to expire (15min?) which is quite
> > > a long time.
> > >
> > > Do you think you can work on a patch?
> > >
> > >> root@mn1:~# ovs-vsctl show
> > >> f6af5f1c-a11c-435f-9b03-7317f364ae48
> > >>Manager "ptcp:6640"
> > >>ovs_version: "2.9.0"
> > >>
> > >> Even thought there is no s1, I still see entries here.
> > >> root@mn1:~# ovs-appctl tnl/arp/show
> > >> IPMAC Bridge
> > >>
> > ==
> > >> 172.168.1.1   02:42:ac:14:00:02   s1
> > >> 172.168.1.2   02:42:ac:14:00:03   s1
> > >> 10.0.0.10 82:ec:29:c0:bc:ef   s1
> > >> 10.0.0.1  d2:54:11:f0:95:df   s1
> > >>
> > >>
> > >> Just for completeness, this is what I had to do to fix my configuration.
> > >>
> > >> Figured out what was wrong with my configuration.
> > >>
> > >> Modify my bridge s1 to be:
> > >>
> > >> ovs-vsctl --may-exist add-br s1 \
> > >>-- set Bridge s1 datapath_type=netdev \
> > >>-- set bridge s1 fail-mode=standalone \
> > >> other_config:hwaddr=$(cat /sys/class/net/eth1/address)
> > >>
> > >> Add the flows:
> > >> ovs-ofctl add-flow s1 "priority=1,in_port=s1-eth1 actions=vxlan"
> > >> ovs-ofctl add-flow s1 "priority=1,in_port=vxlan actions=s1-eth1"
> > >> ovs-ofctl add-flow s1 "priority=0 actions=NORMAL"
> > >>
> > >> ip addr add 1.1.1.1/24 dev s1
> > >> ip link set s1 up
> > >> ip addr flush dev eth1 2>/dev/null
> > >> ip link set eth1 up
> > >>
> > >> ovs-appctl tnl/arp/set s1 1.1.1.2 00:00:01:00:00:02
> > >
> > > Yeah, that will replace the old entry with the new one.
> > >
> > > fbl
> > >
> > >
> > >>
> > >> *Vasu Dasari*
> > >>
> > >>
> > >>> On Tue, Jun 11, 2019 at 6:22 PM Ben Pfaff  wrote:
> > >>>
> > >>>> On Tue, Jun 11, 2019 at 03:17:24PM -0400, Vasu Dasari wrote:
> > >>>> I am running into an issue which sounds pretty basic, probably I
> > might be
> > >>>> missing something.
> > >>>
> > >>> I think you're trying to use kernel tools to configure userspace
> > >>> tunnels.  Did you read Documentation/howto/userspace-tunneling.rst?
> > >>>
> > >
> > >> ___
> > >> 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] VxLAN in Userspace

[Flavio Leitner via discuss]

On Tue, Jun 18, 2019 at 10:41:16AM -0400, Vasu Dasari wrote:
> Flavio,
> 
> The device(could be a regular interface) should have been added to OVS with
> "add-port" and when it is removed, ARP entries learnt on it well be removed
> as well.

Not necessarily. You could have a regular kernel interface with the
tunnel endpoint address which is not part of an OVS bridge.

> The code is ready. Regarding, testing the code I am planning on extending
> already existing case where tests are performed to check ARP entry
> existence, like for example, "tunnel_push_pop - underlay bridge match" in
> tunnel-push-pop.at. I hope that is fine, or should I be writing a separate
> unit test case?

Usually we just add more tests to the file to cover additional
use-cases.

fbl

> 
> -Vasu
> 
> *Vasu Dasari*
> 
> 
> On Fri, Jun 14, 2019 at 9:15 AM Flavio Leitner  wrote:
> 
> > On Thu, Jun 13, 2019 at 10:58:21PM -0400, Vasu Dasari wrote:
> > > Flavio,
> > >
> > > tnl_neigh_cache_flush(), flushes entire tunnel ARP table. When a bridge
> > is
> > > removed, ARP entries learnt on that bridge alone have to be removed.
> > > Entries from other bridges have to be in tact.
> > >
> > > I am thinking of doing the following:
> > >
> > > 1. Write a new API in lib/tnl-neigh-cache.c: tnl_neigh_flush(const char*
> > > br_name) which purges all neighbor entries on bridge br_name.
> >
> > That's better, indeed.
> >
> >
> > > 2. From ofproto/ofproto-dpif-xlate.c: xlate_xbridge_remove() invoke the
> > > function tnl_neigh_flush () to flush the entries.
> > >
> > > til_neigh_xxx() functions are getting called from ofproto-dpif-xlate.c,
> > and
> > > hence thinking that xlate_xbridge_remove() is a right place to do the
> > job.
> > >
> > > What do you think?
> >
> > The device with the IP address can be any regular interface, so
> > do you think it would work if you remove a device that is out of
> > OVS?
> >
> > fbl
> >
> > >
> > > -Vasu
> > >
> > >
> > > On Thu, Jun 13, 2019 at 7:27 PM Vasu Dasari  wrote:
> > >
> > > > Yes Flavio. Looking at code to fix this. Will send fix for review soon.
> > > >
> > > > Vasu
> > > >
> > > > > On Jun 13, 2019, at 7:15 PM, Flavio Leitner 
> > wrote:
> > > > >
> > > > >> On Wed, Jun 12, 2019 at 07:18:27PM -0400, Vasu Dasari wrote:
> > > > >> Thanks Ben. Meanwhile I think I found an bug in OVS 2.9.0 with
> > stale ARP
> > > > >> entries after a bridge is deleted.
> > > > >>
> > > > >> I ran my tunneling experiment successfully. Used mininet to
> > simulate the
> > > > >> environment. After quitting the mininet, switch s1 is deleted. But,
> > I
> > > > still
> > > > >> see the ARP entries in OVS.
> > > > >
> > > > > Looks like when route_table_valid is false we also need to
> > > > > call tnl_neigh_cache_flush() otherwise you will need to wait
> > > > > the ARP entry in the cache to expire (15min?) which is quite
> > > > > a long time.
> > > > >
> > > > > Do you think you can work on a patch?
> > > > >
> > > > >> root@mn1:~# ovs-vsctl show
> > > > >> f6af5f1c-a11c-435f-9b03-7317f364ae48
> > > > >>Manager "ptcp:6640"
> > > > >>ovs_version: "2.9.0"
> > > > >>
> > > > >> Even thought there is no s1, I still see entries here.
> > > > >> root@mn1:~# ovs-appctl tnl/arp/show
> > > > >> IPMAC
> >  Bridge
> > > > >>
> > > >
> > ==
> > > > >> 172.168.1.1   02:42:ac:14:00:02   s1
> > > > >> 172.168.1.2   02:42:ac:14:00:03   s1
> > > > >> 10.0.0.10 82:ec:29:c0:bc:ef   s1
> > > > >> 10.0.0.1  d2:54:11:f0:95:df   s1
> > > > >>
> > > > >>
> > > > >> Just for completeness, this is what I had to do to fix my
> > configuration.
> > > > >>
> > > > >> Figured out what was wrong with my con

Re: [ovs-discuss] losing packets when vxlan port is used

[Flavio Leitner via discuss]

On Wed, Jun 12, 2019 at 02:10:19PM +0200, Miroslav Kubiczek wrote:
> Hello,
> 
> I'm experiencing packets loss on OpenvSwitch host during transmission to
> vxlan port under higher traffic load.
> 
> Some statistics from 2 machines are here (30 seconds run):
> 
> 10.10.12.148-ens224-TX 625 100 %, 2130008249 bytes
> 10.10.12.150-ens224-RX 5999429 99 %, 2129796705 bytes
> 10.10.12.150-vxlan_sys_4789-TX 5641293 94 %, 1923680913 bytes
> 
> 10.10.12.148 - is traffic generator machine
> 10.10.12.150 - is OvS host
> 
> So as you can see about 5% of traffic is lost on OvS. Does anybody have a
> clue why this is happening?
> More configuration details are below.


Checkout the MTU of the interfaces because of VXLAN header size.
Also if it's under heavy load, VXLAN uses UDP and usually NIC
disables hashing on L4 header, which means a single CPU will process
all VXLAN traffic. That could be a bottleneck also.

fbl

> 
> Thank you in advance for any help,
> Miroslav
> 
> 
> /-\ /\
> |10.0.0.2     | |                |
> |   ens224|-|ens224  |
> \_/ |    |
>     | OVS-host       |
> /-\     |                | /-\
> |10.0.0.3     |     |  vxlan_sys_4789||vxlan traffix server |
> |   ens224|-|ens256  | |10.10.12.135 |
> \_/ \/ \_/
> 
> 
> 
> 
> $ sudo ovs-vsctl show
> 68e0245f-1a5f-48ec-a027-a69d839a9b11
>     Bridge "br0"
>     Controller "tcp:127.0.0.1:6653"
>     is_connected: true
>     Port "ens256"
>     Interface "ens256"
>     Port "br0"
>     Interface "br0"
>     type: internal
>     Port vtep
>     Interface vtep
>     type: vxlan
>     options: {key=flow, remote_ip="10.10.12.135"}
>     Port "ens224"
>     Interface "ens224"
>     ovs_version: "2.5.0"
> 
> $ sudo ovs-ofctl dump-flows br0 -O OpenFlow13
> OFPST_FLOW reply (OF1.3) (xid=0x2):
>  cookie=0x0, duration=1265.517s, table=0, n_packets=42029479,
> n_bytes=14920464750, priority=1,in_port=10 actions=resubmit(,2)
>  cookie=0x1, duration=1265.518s, table=0, n_packets=1223020,
> n_bytes=434172100, priority=1000,udp actions=resubmit(,1)
>  cookie=0x0, duration=79826.502s, table=0, n_packets=1236672,
> n_bytes=439008720, priority=10,dl_dst=00:0c:29:42:63:9d actions=output:2
>  cookie=0x0, duration=79794.509s, table=0, n_packets=46, n_bytes=7757,
> priority=10,dl_dst=00:0c:29:ec:54:7b actions=output:1
>  cookie=0x0, duration=79826.501s, table=0, n_packets=11, n_bytes=850,
> priority=1,in_port=2,dl_dst=00:0c:29:ec:54:7b actions=output:2
>  cookie=0x0, duration=79836.182s, table=0, n_packets=2, n_bytes=158,
> priority=0 actions=CONTROLLER:65535
>  cookie=0x0, duration=1265.517s, table=1, n_packets=49579226,
> n_bytes=17600625230, actions=output:10
>  cookie=0x0, duration=79826.501s, table=2, n_packets=42029478,
> n_bytes=14920464690, priority=100,ip,dl_dst=00:0c:29:42:63:9d
> actions=output:2
>  cookie=0x0, duration=79794.509s, table=2, n_packets=0, n_bytes=0,
> priority=100,ip,dl_dst=00:0c:29:ec:54:7b actions=output:1
> 
> $ ovs-vsctl --version
> ovs-vsctl (Open vSwitch) 2.5.0
> Compiled Apr 28 2016 10:25:38
> DB Schema 7.12.1
> 
> 
> ___
> 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] VxLAN in Userspace

[Flavio Leitner via discuss]

On Wed, Jun 12, 2019 at 07:18:27PM -0400, Vasu Dasari wrote:
> Thanks Ben. Meanwhile I think I found an bug in OVS 2.9.0 with stale ARP
> entries after a bridge is deleted.
> 
> I ran my tunneling experiment successfully. Used mininet to simulate the
> environment. After quitting the mininet, switch s1 is deleted. But, I still
> see the ARP entries in OVS.

Looks like when route_table_valid is false we also need to 
call tnl_neigh_cache_flush() otherwise you will need to wait
the ARP entry in the cache to expire (15min?) which is quite
a long time.

Do you think you can work on a patch?

> root@mn1:~# ovs-vsctl show
> f6af5f1c-a11c-435f-9b03-7317f364ae48
> Manager "ptcp:6640"
> ovs_version: "2.9.0"
> 
> Even thought there is no s1, I still see entries here.
> root@mn1:~# ovs-appctl tnl/arp/show
> IPMAC Bridge
> ==
> 172.168.1.1   02:42:ac:14:00:02   s1
> 172.168.1.2   02:42:ac:14:00:03   s1
> 10.0.0.10 82:ec:29:c0:bc:ef   s1
> 10.0.0.1  d2:54:11:f0:95:df   s1
> 
> 
> Just for completeness, this is what I had to do to fix my configuration.
> 
> Figured out what was wrong with my configuration.
> 
> Modify my bridge s1 to be:
> 
> ovs-vsctl --may-exist add-br s1 \
> -- set Bridge s1 datapath_type=netdev \
> -- set bridge s1 fail-mode=standalone \
>  other_config:hwaddr=$(cat /sys/class/net/eth1/address)
> 
> Add the flows:
> ovs-ofctl add-flow s1 "priority=1,in_port=s1-eth1 actions=vxlan"
> ovs-ofctl add-flow s1 "priority=1,in_port=vxlan actions=s1-eth1"
> ovs-ofctl add-flow s1 "priority=0 actions=NORMAL"
> 
> ip addr add 1.1.1.1/24 dev s1
> ip link set s1 up
> ip addr flush dev eth1 2>/dev/null
> ip link set eth1 up
> 
> ovs-appctl tnl/arp/set s1 1.1.1.2 00:00:01:00:00:02

Yeah, that will replace the old entry with the new one.

fbl


> 
> *Vasu Dasari*
> 
> 
> On Tue, Jun 11, 2019 at 6:22 PM Ben Pfaff  wrote:
> 
> > On Tue, Jun 11, 2019 at 03:17:24PM -0400, Vasu Dasari wrote:
> > > I am running into an issue which sounds pretty basic, probably I might be
> > > missing something.
> >
> > I think you're trying to use kernel tools to configure userspace
> > tunnels.  Did you read Documentation/howto/userspace-tunneling.rst?
> >

> ___
> 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] VxLAN in Userspace

[Flavio Leitner via discuss]

On Tue, Jun 18, 2019 at 03:12:51PM -0400, Vasu Dasari wrote:
> On Tue, Jun 18, 2019 at 12:21 PM Flavio Leitner  wrote:
> 
> > On Tue, Jun 18, 2019 at 10:41:16AM -0400, Vasu Dasari wrote:
> > > Flavio,
> > >
> > > The device(could be a regular interface) should have been added to OVS
> > with
> > > "add-port" and when it is removed, ARP entries learnt on it well be
> > removed
> > > as well.
> >
> > Not necessarily. You could have a regular kernel interface with the
> > tunnel endpoint address which is not part of an OVS bridge.
> >
> 
> The code being added should cover that as well. Probably you can comment on
> this after you look at my code.

OK.

> > > The code is ready. Regarding, testing the code I am planning on extending
> > > already existing case where tests are performed to check ARP entry
> > > existence, like for example, "tunnel_push_pop - underlay bridge match" in
> > > tunnel-push-pop.at. I hope that is fine, or should I be writing a
> > separate
> > > unit test case?
> >
> > Usually we just add more tests to the file to cover additional
> > use-cases.
> >
> > Ok. Will add a new test case then.
> 
> On another note, I see ARP neighbor add and show commands. This covers L3
> side. For L2 side, I see fdb show command, but there is no set command. I
> would like to add that one also. Any comments?
> 
> Current fdb show:
> ovs-appctl fdb/show s1
> 
> Proposed CLI for fdb/set operation would look like:
> ovs-appctl fdb/set
> ovs-appctl fdb/set s1 2 0 00:00:01:00:00:02
> 
> What do you think?

One could add a flow to match on specific MAC and send out on a
specific port as an alternative solution which is not possible to
regular bridges.

On another hand, for use cases where the flow table last action is
NORMAL, then having static entries might be interesting because
today the FDB has only learned packets which expire/update
dynamically. You also need a way to remove specific static entries
because flushing the whole table has non trivial networking side
effects.

If you want to pursue that too, I suggest to do as a separate
patchset to not mix bug fixes with enhancements.

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

Re: [ovs-discuss] ovs-vswitchd port limit with OpenStack

[Flavio Leitner via discuss]

On Thu, May 02, 2019 at 04:44:42PM -0300, Flavio Leitner via discuss wrote:
> On Tue, Apr 30, 2019 at 04:50:48PM -0700, Ben Pfaff wrote:
> > On Fri, Apr 26, 2019 at 11:52:22AM -0500, William Konitzer wrote:
> > > I'm reading
> > > (http://www.openvswitch.org/support/dist-docs/ovs-vswitchd.8.txt
> > > section LIMITS) and it says "Performance will degrade beyond 1,024
> > > ports per bridge due to fixed hash table sizing.” Do we have a little
> > > more info on what that means and what to expect for less experienced
> > > users like myself?
> > 
> > I think that this comment is now obsolete.  There was a fairly recent
> > change that should have reduced the cost of a port.  The kernel hash
> > table is still fixed in size but I don't think it's accessed on any fast
> > path so I think in practice it doesn't matter.
> > 
> > > The background here is we’re working with OpenStack and seeing
> > > performance issues when lots of networks are created.. Once we have
> > > more than about 1500 ports on the br-int on a gateway node it seems to
> > > take a long time to add new ports.
> 
> You might want to bump the default netdev_max_backlog because that
> is the maximum amount of packets queued. So, if you have too many
> ports, there will be either packet loss, or slow path'ed traffic.

To clarify, it depends on the actions. If you are using action
NORMAL and there is a broadcast for example, all ports need a
packet copy, which means more than 1k packets will be queued.
IIRC OvS will slow path this case to prevent packet loss in
the recent versions.

fbl

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

Re: [ovs-discuss] ovs-vswitchd port limit with OpenStack

[Flavio Leitner via discuss]

On Tue, Apr 30, 2019 at 04:50:48PM -0700, Ben Pfaff wrote:
> On Fri, Apr 26, 2019 at 11:52:22AM -0500, William Konitzer wrote:
> > I'm reading
> > (http://www.openvswitch.org/support/dist-docs/ovs-vswitchd.8.txt
> > section LIMITS) and it says "Performance will degrade beyond 1,024
> > ports per bridge due to fixed hash table sizing.” Do we have a little
> > more info on what that means and what to expect for less experienced
> > users like myself?
> 
> I think that this comment is now obsolete.  There was a fairly recent
> change that should have reduced the cost of a port.  The kernel hash
> table is still fixed in size but I don't think it's accessed on any fast
> path so I think in practice it doesn't matter.
> 
> > The background here is we’re working with OpenStack and seeing
> > performance issues when lots of networks are created.. Once we have
> > more than about 1500 ports on the br-int on a gateway node it seems to
> > take a long time to add new ports.

You might want to bump the default netdev_max_backlog because that
is the maximum amount of packets queued. So, if you have too many
ports, there will be either packet loss, or slow path'ed traffic.

fbl


> > 
> > I’m trying to quickly determine if we have a config issue, an
> > Openstack issue or whether we’re hitting some sort of OVS limit as
> > described. It seems to me that 1500 ports isn’t that many, but I’m not
> > sure what sort of performance degradation I should be expecting above
> > 1024 ports. The gateway node is so lightly loaded that I’d prefer to
> > be able to handle a lot more networks on it before deploying another
> > one.
> 
> Are you adding ports one at a time with ovs-vsctl?  If you can add them
> in a batch, it will perform better.  I guess we could also add a "daemon
> mode" like ovn-nbctl, which would help a good deal too.
> ___
> 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 with or without DPDK Throughput issue

[Flavio Leitner via discuss]

On Wed, 31 Jan 2024 17:45:30 -0800
MIchael Miller via discuss  wrote:

> Hi All,
> 
>   Not sure if this is the right forum for this question but figured I 
> would start here.
> 
>   Have implemented several dedicated kvm based private virtualization 
> server in several Outside Data Center (have no access to
> router/switch configs), Base host is Rocky Linux 9 with OVS 3.2.1
> with dpdk 22.11 complied from source and from that I have created two
> ovs bridges groups, "br-ex" is attached to 10Gbps Server NIC Card and
> vhost-net attached to a KVM running a firewall/router/vpn appliance
> ("WAN" Port), 2nd group is "br-int" which creates a form of a lan
> network without a physical NIC card, this is attached to the KVM
> running the firewall/router/vpn appliance as a "LAN" Port and any KVM
> guest as well via a vhost-net style config. When I test from Base
> Host via speedtest or iperf3, results vary but are typically
> 8+/8+Gbps  and same test from KVM guest results in 4/4Gbps which
> sounds great in theory but actually throughput between KVM guests or
> KVM guest and outside world varies, have seen 31Gb take 15 minutes
> and have seen the same 31GB take several hours.


Look at the CPU usage while testing it. Most probably there are
threads scheduled over the same CPU causing the tput to go down.
See this recommendation as an example:
https://access.redhat.com/documentation/pt-br/red_hat_openstack_platform/10/html/ovs-dpdk_end_to_end_troubleshooting_guide/using_virsh_emulatorpin_in_virtual_environments_with_nfv

fbl


> 
>   Have gone down the rabbit hole of maybe the firewall/router/vpn 
> appliance can't handle it but have tried two different vendor
> products: Sonicwall and Mikrotik CHR both have similar results. I
> have also tested a Rocky LInux KVM guest directly attached to the
> "br-ex" group but the results also show degraded performance, which
> is leading me to believe something might have been missed in the OVS
> setup.
> 
> 
> br-ex/br-int kvm nic config (difference is source bridge line and
> slot= line):
> 
> 
>    
>    
>    
>      
>    
>    
>    
>     event_idx="off" queues="8"/>  
>    
>     function="0x0"/>  
> 
> 
> 



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

Re: [ovs-discuss] Urgent Help needed: OVS 3.2.2 Strange TC DROPs

[Flavio Leitner via discuss]

Hi Gavin,

It would be helpful if you can provide some TC dumps from the 
"good" state to the "bad" state to see how it was and what changes. 
Something like:

# tc -s filter show dev enp148s0f0_1 ingress

I haven't checked the attached files, but one suggestion is to 
check if this is not a csum issue.

Thanks,
fbl


On Tue, 16 Apr 2024 13:17:10 -0700
Gavin McKee via discuss  wrote:

> Adding information relating to the Open VSwitch kernal module
> @Ilya Maximets @Numan Siddique  Can either of you help out here?
> 
> 
> modinfo openvswitch
> filename:
> /lib/modules/5.14.0-362.8.1.el9_3.x86_64/kernel/net/openvswitch/openvswitch.ko.xz
> alias:  net-pf-16-proto-16-family-ovs_ct_limit
> alias:  net-pf-16-proto-16-family-ovs_meter
> alias:  net-pf-16-proto-16-family-ovs_packet
> alias:  net-pf-16-proto-16-family-ovs_flow
> alias:  net-pf-16-proto-16-family-ovs_vport
> alias:  net-pf-16-proto-16-family-ovs_datapath
> license:GPL
> description:Open vSwitch switching datapath
> rhelversion:9.3
> srcversion: 8A2159D727C8BADC82261B8
> depends:nf_conntrack,nf_conncount,libcrc32c,nf_nat
> retpoline:  Y
> intree: Y
> name:   openvswitch
> vermagic:   5.14.0-362.8.1.el9_3.x86_64 SMP preempt mod_unload
> modversions sig_id: PKCS#7
> signer: Rocky kernel signing key
> sig_key:
> 17:CA:DE:1F:EC:D1:59:2D:9F:52:34:C6:7C:09:06:81:3D:74:7C:F7
> sig_hashalgo:   sha256 signature:
> 67:31:56:70:86:DB:57:69:8D:4A:9B:A7:ED:17:F3:67:65:98:97:08:
> 1F:FB:4D:F8:A8:2D:7C:A7:7D:3A:57:85:CA:67:9D:82:72:EB:54:14:
> F2:BB:40:78:AD:85:56:2D:EF:D5:00:95:38:A4:86:9F:5F:29:1A:81:
> 32:94:B4:87:41:94:A0:3E:71:A5:97:44:2E:42:DD:F7:42:6B:69:94:
> E3:AB:6E:E5:4F:C9:60:57:70:07:5F:CA:C7:83:7A:2F:C7:81:62:FF:
> 53:AF:AC:2B:06:D8:08:D3:1D:A7:F0:43:10:98:DE:B1:62:AE:89:A5:
> FE:EF:74:09:0F:2D:0F:D9:73:A5:59:75:D0:87:1E:EA:3A:40:86:1E:
> 76:E5:E7:3B:59:2E:3A:7E:65:F3:92:A1:B4:84:48:3F:43:A0:D7:1C:
> 21:29:E0:B6:D1:10:36:15:88:43:6A:11:8F:55:EE:1B:F9:53:3B:86:
> EF:81:71:17:81:08:EC:53:30:D6:69:8E:13:11:D5:DF:15:75:88:50:
> 69:19:51:3B:41:6B:6F:E0:7A:30:33:32:E6:60:18:02:A6:0C:63:9B:
> C5:D7:2F:6A:D0:BA:45:03:19:0E:21:E8:18:FB:E8:D1:C1:33:05:36:
> 1F:9B:0F:29:3F:05:51:7A:30:86:88:B7:C7:44:2E:2B:50:F9:EF:4F:
> D4:70:EA:1B:33:E2:F0:E3:E2:88:00:E5:BF:06:E2:D4:B7:81:EE:6E:
> 89:02:18:65:8B:1C:84:42:2F:89:14:63:1D:51:70:37:42:C5:68:DD:
> 4D:12:7B:07:33:2B:C6:BC:8F:7F:23:D7:58:DF:47:AC:DE:08:67:FE:
> CB:E8:E6:4D:95:2F:6B:F5:07:4D:32:92:80:0A:7C:D1:B6:81:EE:AB:
> 26:C3:C6:22:77:00:5E:64:DE:96:0E:9F:A4:A0:F0:45:9F:19:73:EB:
> CC:60:AE:E9:63:E2:6D:2E:BA:65:9B:BD:04:CC:13:C2:55:88:05:03:
> 1B:30:18:8B
> 
> On Tue, 16 Apr 2024 at 11:12, Gavin McKee 
> wrote:
> >
> > Hi,
> >
> > I need some help with strange OVS behaviours.
> >
> > ovs-vsctl (Open vSwitch) 3.2.2
> > ovn-controller 23.09.1
> > Open vSwitch Library 3.2.2
> >
> > TLDR: We need to restart Open VSwitch in order for TLS traffic to
> > work between a VM and Cloudflare R2.  After restarting Open VSwitch
> > the TLS connection works fine.
> > (see attached pcap tls-error.txt)
> >
> > See the attached openflow traces - they show a flow trace from Open
> > Vswitch.
> >
> > Also there is a retis trace (retis tool discussed at Open VSwitch
> > conference 2023).
> >
> > Note the drop (TC_INGRESS) in this file
> >   + 1702601116185568 [swapper/140] 0 [tp] skb:kfree_skb
> > #60c81b6b91e2cff284fb3a3d65800 (skb 18386033671255367680) n 3 drop
> > (TC_INGRESS)
> > if 21 (enp148s0f0_1) rxif 21 172.27.18.244.57394 >
> > 104.18.2.35.443 ttl 63 tos 0x0 id 26162 off 0 [DF] len 477 proto
> > TCP (6) flags [P.] seq 792060930:792061367 ack 951229219 win 11
> >
> > Again , once I restart Open vSwitch the problem goes away for a time
> > and comes back sometime later (not sure what that time frame is but
> > its a recurring issue.)  
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss



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

Re: [ovs-discuss] Urgent Help needed: OVS 3.2.2 Strange TC DROPs

[Flavio Leitner via discuss]

On Wed, 17 Apr 2024 12:26:27 -0700
Gavin McKee  wrote:

> Hi Flavio,
> 
> I had to restart the Open vSwitch across 16 machines to resolve the
> issue for a customer .  I think it will occur again and when it does
> I'll use that command to gather the tc information.
> 
> Until then I think I have found why the issue is occurring .
> 
> Take a look at the output below (this is a packet capture from the
> physical interface on the compute node , so traffic that has gone
> through the OVS Openflow pipeline) - we make a 3 way handshake with R2
> , and establish the connection.  A packet goes missing - TLS
> handshake, it then appears that it hasn't gone through NAT as it's
> using the Private IP of the VM  .


If that is the case, you might be able to see if the data path 
is matching correctly and the actions are using NAT with 
ovs-appctl ofproto/trace.

fbl


> 
> Take a look at frame 14
> 
> No. Time   SourceDestination
> Protocol Length Info
>  Delta
>  14 09:24:08.064432172.27.18.244 104.18.2.35
> TLSv1502Client Hello, Alert (Level: Fatal, Description: Decode
> Error)   2.362983
> 
> Frame 14: 502 bytes on wire (4016 bits), 502 bytes captured (4016
> bits) Ethernet II, Src: 4e:42:14:a1:2a:fb (4e:42:14:a1:2a:fb), Dst:
> IETF-VRRP-VRID_ff (00:00:5e:00:01:ff)
> 802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 120
> Internet Protocol Version 4, Src: 172.27.18.244, Dst: 104.18.2.35
> Transmission Control Protocol, Src Port: 57394, Dst Port: 443, Seq: 1,
> Ack: 1, Len: 444
> Transport Layer Security
> TLSv1 Record Layer: Handshake Protocol: Client Hello
> Content Type: Handshake (22)
> Version: TLS 1.0 (0x0301)
> Length: 432
> Handshake Protocol: Client Hello
> TLSv1 Record Layer: Alert (Level: Fatal, Description: Decode
> Error) Content Type: Alert (21)
> Version: TLS 1.0 (0x0301)
> Length: 2
> Alert Message
> Level: Fatal (2)
> Description: Decode Error (50)
> 
> 
> 
> --------
> 
> On Wed, 17 Apr 2024 at 11:28, Flavio Leitner  wrote:
> >
> >
> > Hi Gavin,
> >
> > It would be helpful if you can provide some TC dumps from the
> > "good" state to the "bad" state to see how it was and what changes.
> > Something like:
> >
> > # tc -s filter show dev enp148s0f0_1 ingress
> >
> > I haven't checked the attached files, but one suggestion is to
> > check if this is not a csum issue.
> >
> > Thanks,
> > fbl
> >
> >
> > On Tue, 16 Apr 2024 13:17:10 -0700
> > Gavin McKee via discuss  wrote:
> >  
> > > Adding information relating to the Open VSwitch kernal module
> > > @Ilya Maximets @Numan Siddique  Can either of you help out here?
> > >
> > >
> > > modinfo openvswitch
> > > filename:
> > > /lib/modules/5.14.0-362.8.1.el9_3.x86_64/kernel/net/openvswitch/openvswitch.ko.xz
> > > alias:  net-pf-16-proto-16-family-ovs_ct_limit
> > > alias:  net-pf-16-proto-16-family-ovs_meter
> > > alias:  net-pf-16-proto-16-family-ovs_packet
> > > alias:  net-pf-16-proto-16-family-ovs_flow
> > > alias:  net-pf-16-proto-16-family-ovs_vport
> > > alias:  net-pf-16-proto-16-family-ovs_datapath
> > > license:GPL
> > > description:Open vSwitch switching datapath
> > > rhelversion:9.3
> > > srcversion: 8A2159D727C8BADC82261B8
> > > depends:nf_conntrack,nf_conncount,libcrc32c,nf_nat
> > > retpoline:  Y
> > > intree: Y
> > > name:   openvswitch
> > > vermagic:   5.14.0-362.8.1.el9_3.x86_64 SMP preempt mod_unload
> > > modversions sig_id: PKCS#7
> > > signer: Rocky kernel signing key
> > > sig_key:
> > > 17:CA:DE:1F:EC:D1:59:2D:9F:52:34:C6:7C:09:06:81:3D:74:7C:F7
> > > sig_hashalgo:   sha256 signature:
> > > 67:31:56:70:86:DB:57:69:8D:4A:9B:A7:ED:17:F3:67:65:98:97:08:
> > > 1F:FB:4D:F8:A8:2D:7C:A7:7D:3A:57:85:CA:67:9D:82:72:EB:54:14:
> > > F2:BB:40:78:AD:85:56:2D:EF:D5:00:95:38:A4:86:9F:5F:29:1A:81:
> > > 32:94:B4:87:41:94:A0:3E:71:A5:97:44:2E:42:DD:F7:42:6B:69:94:
> > > E3:AB:6E:E5:4F:C9:60:57:70:07:5F:CA:C7:83:7A:2F:C7:81:62:FF:
> > > 53:AF:AC:2B:06:D8:08:D3:1D:A7:F0:43:10:98:DE:B1:62:AE:89:A5:
> > > FE:EF:74:09:0F:2D:0F:D9:73:A5:59:75:D0:87:1E:EA:3A:40:86:1E:
> > > 76:E5:E7:3B:59:2E:3A:7E:65:F3:

Re: [ovs-discuss] Open V Switch module

[Flavio Leitner via discuss]

On Fri, 3 May 2024 17:45:42 -0700
Abu Rasheda via discuss  wrote:

> Since the OVS kernel code has moved to the Linux kernel tree since the
> 3.0 release. I did not find the module in /lib/module on Redhat 9.3,
> but I did find it in
> 
> ./modules/6.2.0-39-generic/kernel/net/openvswitch/openvswitch.ko (For
> Ubuntu 22)
> 
> Can someone guide me on how to obtain vendor (Redhat) provided OVS
> kernel modules for distribution based on Linux kernel within kernel
> tree OVS?


The module is shipped as part of the kernel-modules-core RPM package:

$ rpm -qpl
~/Downloads/kernel-modules-core*.x86_64.rpm | grep openvswitch 

/lib/modules/5.14.0-362.8.1.el9_3.x86_64/kernel/net/openvswitch
/lib/modules/5.14.0-362.8.1.el9_3.x86_64/kernel/net/openvswitch/openvswitch.ko.xz
/lib/modules/5.14.0-362.8.1.el9_3.x86_64/kernel/net/openvswitch/vport-geneve.ko.xz
/lib/modules/5.14.0-362.8.1.el9_3.x86_64/kernel/net/openvswitch/vport-gre.ko.xz
/lib/modules/5.14.0-362.8.1.el9_3.x86_64/kernel/net/openvswitch/vport-vxlan.ko.xz
/lib/modules/5.14.0-427.13.1.el9_4.x86_64/kernel/net/openvswitch
/lib/modules/5.14.0-427.13.1.el9_4.x86_64/kernel/net/openvswitch/openvswitch.ko.xz
/lib/modules/5.14.0-427.13.1.el9_4.x86_64/kernel/net/openvswitch/vport-geneve.ko.xz
/lib/modules/5.14.0-427.13.1.el9_4.x86_64/kernel/net/openvswitch/vport-gre.ko.xz
/lib/modules/5.14.0-427.13.1.el9_4.x86_64/kernel/net/openvswitch/vport-vxlan.ko.xz


HTH,
fbl

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