[ovs-discuss] with vhostuser I cannot use hugepages

[Adnan Mundres via discuss]

I am using red-hat 7.4 and ovs 2.6.1 with dpdk 16.11
In my setup I am using qemu-kvm without openstack. I am trying to use ovs with 
dpdk. In my xml file I added following lines for the dpdkvhostuser
                

I have enabled hugepages during boot time
ot@mvmgptb11hyp01 hyp-1]# cat /proc/meminfo | grep -i hugeAnonHugePages: 126976 
kBHugePages_Total: 100HugePages_Free: 80HugePages_Rsvd: 0HugePages_Surp: 
0Hugepagesize: 1048576 kB
But When I start my vm (virsh start vm1.xml) I am seeing that this vm is not 
using memory from hugepages, rather it is taking memory from total memory. When 
I checked the log file I see that it is 
usingmem-path=/var/lib/libvirt/qemu/ram,share=yes
It should use backend memory as following
mem-path=/dev/hugepages/libvirt/qemu/vm1,share=yes
Any idea how can I use memory from hugepages~                                   
            ___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] Question about Rx mergeable buffer

[王志克]

Hi,

I have question about RX merge feature.
Below mentions that set mrg_rxbuf=off can improve performance.  So question 1:
How much would it be affected for throughput?

*
Rx Mergeable 
Buffers¶

Rx mergeable buffers is a virtio feature that allows chaining of multiple 
virtio descriptors to handle large packet sizes. Large packets are handled by 
reserving and chaining multiple free descriptors together. Mergeable buffer 
support is negotiated between the virtio driver and virtio device and is 
supported by the DPDK vhost library. This behavior is supported and enabled by 
default, however in the case where the user knows that rx mergeable buffers are 
not needed i.e. jumbo frames are not needed, it can be forced off by adding 
mrg_rxbuf=off to the QEMU command line options. By not reserving multiple 
chains of descriptors it will make more individual virtio descriptors available 
for rx to the guest using dpdkvhost ports and this can improve performance.
***

http://docs.openvswitch.org/en/latest/howto/dpdk/?highlight=mrg_rxbuf

It mentions mrg_rxbuf must be set to on in order to support Jumbo frames.

So question 2: I am wondering if I set mtu to 2000, should mrg_rxbuf be also a 
MUST? Is there a threshold to switch the configuration?


Some additional configuration is needed to take advantage of jumbo frames with 
vHost ports:
mergeable buffers must be enabled for vHost ports, as demonstrated in the QEMU 
command line snippet below:”.
**

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

Re: [ovs-discuss] Windows test: 1077. ofproto-dpif.at:1663: testing ofproto-dpif - controller action without megaflows

[Alin Serdean]

TBH I haven't looked into details.

I will do this tomorrow.

Thanks a lot,
Alin.

> -Original Message-
> From: Ben Pfaff [mailto:b...@ovn.org]
> Sent: Tuesday, January 23, 2018 2:19 AM
> To: Alin Serdean 
> Cc: b...@openvswitch.org
> Subject: Re: [ovs-discuss] Windows test: 1077. ofproto-dpif.at:1663: testing
> ofproto-dpif - controller action without megaflows
> 
> Certainly these are odd results showing that on Windows an extra packet
> passes through the rate limiter.  Do you have any leads on a possible
> solution?  Does timing work somehow different on Windows?
> 
> On Sun, Jan 14, 2018 at 05:11:00PM +, Alin Serdean wrote:
> > ofproto-dpif
> >
> > 1077. ofproto-dpif.at:1663: testing ofproto-dpif - controller action without
> megaflows ...
> > ./ofproto-dpif.at:1664: ovsdb-tool create conf.db
> > $abs_top_srcdir/vswitchd/vswitch.ovsschema
> > ./ofproto-dpif.at:1664: ovsdb-server --detach --no-chdir --pidfile
> > --log-file --remote=punix:$OVS_RUNDIR/db.sock
> > stderr:
> > ./ofproto-dpif.at:1664: sed < stderr '
> > /vlog|INFO|opened log file/d
> > /ovsdb_server|INFO|ovsdb-server (Open vSwitch)/d'
> > ./ofproto-dpif.at:1664: ovs-vsctl --no-wait init
> > ./ofproto-dpif.at:1664: ovs-vswitchd --enable-dummy --disable-system
> > --detach --no-chdir --pidfile --log-file -vvconn -vofproto_dpif
> > -vunixctl
> > stderr:
> > ./ofproto-dpif.at:1664: sed < stderr '
> > /ovs_numa|INFO|Discovered /d
> > /vlog|INFO|opened log file/d
> > /vswitchd|INFO|ovs-vswitchd (Open vSwitch)/d /reconnect|INFO|/d
> > /ofproto|INFO|using datapath ID/d /netdev_linux|INFO|.*device has
> > unknown hardware address family/d /ofproto|INFO|datapath ID changed
> to
> > fedcba9876543210/d /dpdk|INFO|DPDK Disabled - Use
> > other_config:dpdk-init to enable/d
> > /netdev: Flow API/d
> > /tc: Using policy/d'
> > ./ofproto-dpif.at:1664: add_of_br 0
> > ovs-vsctl -- add-port br0 p1 -- set Interface p1 type=dummy
> > ofport_request=1
> > ./ofproto-dpif.at:1667: ovs-ofctl add-flow br0
> > in_port=1,action=controller
> > ./ofproto-dpif.at:1668: ovs-appctl upcall/disable-megaflows
> > ./ofproto-dpif.at:1673: ovs-ofctl monitor br0 65534 invalid_ttl -P
> > nxt_packet_in --detach --no-chdir --pidfile 2> ofctl_monitor.log
> > ./ofproto-dpif.at:1676: ovs-appctl netdev-dummy/receive p1
> 'in_port(1),eth(src=50:54:00:00:00:09,dst=50:54:00:00:00:0a),eth_type(0x123
> 4)'
> > ./ofproto-dpif.at:1676: ovs-appctl netdev-dummy/receive p1
> 'in_port(1),eth(src=50:54:00:00:00:09,dst=50:54:00:00:00:0a),eth_type(0x123
> 4)'
> > ./ofproto-dpif.at:1682: ovs-appctl dpctl/dump-flows | sed
> 's/.*\(packets:\)/\1/' | sed 's/used:[0-9].[0-9]*s/used:0.001s/'
> > ./ofproto-dpif.at:1687: cat ofctl_monitor.log
> > ./ofproto-dpif.at:1694: ovs-appctl revalidator/purge
> > ./ofproto-dpif.at:1695: ovs-ofctl monitor br0 65534 invalid_ttl -P
> > nxt_packet_in --detach --no-chdir --pidfile 2> ofctl_monitor.log
> > ./ofproto-dpif.at:1698: ovs-ofctl -O OpenFlow13 add-meter br0
> 'meter=controller pktps stats bands=type=drop rate=2'
> > ./ofproto-dpif.at:1701: ovs-appctl time/warp 1000
> > stdout:
> > warped
> > ./ofproto-dpif.at:1704: ovs-appctl netdev-dummy/receive p1
> 'in_port(1),eth(src=50:54:00:00:00:09,dst=50:54:00:00:00:0a),eth_type(0x432
> 1)'
> > ./ofproto-dpif.at:1704: ovs-appctl netdev-dummy/receive p1
> 'in_port(1),eth(src=50:54:00:00:00:09,dst=50:54:00:00:00:0a),eth_type(0x432
> 1)'
> > ./ofproto-dpif.at:1704: ovs-appctl netdev-dummy/receive p1
> 'in_port(1),eth(src=50:54:00:00:00:09,dst=50:54:00:00:00:0a),eth_type(0x432
> 1)'
> > ./ofproto-dpif.at:1704: ovs-appctl netdev-dummy/receive p1
> 'in_port(1),eth(src=50:54:00:00:00:09,dst=50:54:00:00:00:0a),eth_type(0x432
> 1)'
> > ./ofproto-dpif.at:1704: ovs-appctl netdev-dummy/receive p1
> 'in_port(1),eth(src=50:54:00:00:00:09,dst=50:54:00:00:00:0a),eth_type(0x432
> 1)'
> > ./ofproto-dpif.at:1704: ovs-appctl netdev-dummy/receive p1
> 'in_port(1),eth(src=50:54:00:00:00:09,dst=50:54:00:00:00:0a),eth_type(0x432
> 1)'
> > ./ofproto-dpif.at:1704: ovs-appctl netdev-dummy/receive p1
> 'in_port(1),eth(src=50:54:00:00:00:09,dst=50:54:00:00:00:0a),eth_type(0x432
> 1)'
> > ./ofproto-dpif.at:1704: ovs-appctl netdev-dummy/receive p1
> 'in_port(1),eth(src=50:54:00:00:00:09,dst=50:54:00:00:00:0a),eth_type(0x432
> 1)'
> > ./ofproto-dpif.at:1707: ovs-appctl dpctl/dump-flows | sed
> 's/.*\(packets:\)/\1/' | sed 's/used:[0-9].[0-9]*s/used:0.001s/'
> > ./ofproto-dpif.at:1712: ovs-appctl time/warp 1
> > stdout:
> > warped
> > ./ofproto-dpif.at:1717: cat ofctl_monitor.log
> > --- -   2018-01-14 19:07:32 +0200
> > +++ /c/_2018/january/14/ovs/tests/testsuite.dir/at-groups/1077/stdout
> 2018-01-14 19:07:33 +0200
> > @@ -2,4 +2,6 @@
> >
> > vlan_tci=0x,dl_src=50:54:00:00:00:09,dl_dst=50:54:00:00:00:0a,dl_t
> > ype=0x4321  NXT_PACKET_IN (xid=0x0): cookie=0x0 total_len=14
> in_port=1
> > (via action) data_len=14 (unbuffered)
> >
> > vlan_tci=0x,dl_src=50:54:00:00:00:09,dl_dst=50:54:00:00:00:0a,dl_t
> 

Re: [ovs-discuss] [ovs-dev] mbuf pool sizing

[Kevin Traynor]

On 01/23/2018 11:42 AM, Kevin Traynor wrote:
> On 01/17/2018 07:48 PM, Venkatesan Pradeep wrote:
>> Hi,
>>
>> Assuming that all ports use the same MTU,  in OVS2.8 and earlier, a single 
>> mempool of 256K buffers (MAX_NB_MBUF = 4096 * 64) will be created and shared 
>> by all the ports
>>
>> With the OVS2.9 mempool patches, we have port specific allocation and the 
>> number of mbufs created for each port is based on the following formula 
>> (with a lower limit of MIN_NB_MBUF = 4096*4)
>>n_mbufs = dev->requested_n_rxq * dev->requested_rxq_size
>>   + dev->requested_n_txq * dev->requested_txq_size
>>   + MIN(RTE_MAX_LCORE, dev->requested_n_rxq) * NETDEV_MAX_BURST
>>   + MIN_NB_MBUF;
>>
>> Using minimal value (1) for n_rxq and n_rxq and default value (2048) for 
>> requested_rxq_size and requested_txq_size, the above translates to
>>   n_mbufs = 1*2048 + 1*2048 + 1*32 + 4096*4  = 20512
>>
>> Assuming all ports have the same MTU, this means that approximately 13 ports 
>> in OVS2.9 will consume as much memory as the single mempool shared by all 
>> ports in OVS2.8 (256*1024 / 20512) .
>>
>> When a node is upgraded from OVS2.8 to OVS2.9 it is quite possible that the 
>> memory set aside for OVS may be insufficient. I'm not sure if this aspect 
>> has been discussed previously and wanted to bring this up for discussion.
>>
> 
> Hi Pradeep, I don't think it has been discussed. I guess the thinking
> was that with a giant shared mempool, it was over provisioning when
> there was a few ports, and in the case where there was a lot of ports
> there could be some starvation at run time. It also meant if you had a
> mix of different MTU's you had multiple giant shared mempools and could
> run out of memory very quickly at config or run time then also.
> 
> So I can see the argument for having a mempool per port, as it is more
> fine grained and if you are going to run short of memory, it will at
> least be at config time. The problem is if you give some over provision
> to each port and you have a lot of ports, you hit the situation you are
> seeing.
> 
> I think some amount of over provision per port is needed because you
> don't want to be cutting it so fine that you run into memory issues at
> run time about local mbuf caches on cores running out, or even if
> someone used dpdk rings to send the mbuf somewhere else for a time.
> There may be other corner cases too. Perhaps as compromise the min size
> could be reduce from 4096*4 to 4096*2 or 4096.
> 
> Thoughts?
> 

I just sent a compile tested only RFC here
https://mail.openvswitch.org/pipermail/ovs-dev/2018-January/343581.html

> Kevin.
> 
>> Regards,
>>
>> Pradeep
>>
>>
>> ___
>> dev mailing list
>> d...@openvswitch.org
>> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>>
> 
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
> 

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

Re: [ovs-discuss] OVS delete port by itself

[Ben Pfaff]

On Tue, Jan 23, 2018 at 10:41:21AM +0800, netsurfed wrote:
> Hi all,
> 
> 
> When I created a virtual machine using libvirt, with virtualport type was 
> openvswitch, and virtual machine creation failed. The Domain XML file the 
>  section like this:
> 
> 
> I looked at the system log and it looked like an ovs port problem.
> 
> 
> And the ovs-vswitchd.log was:
> 
> 
> Is there any reason for this problem? Thank you very much.
> Below some information about my machine:
> ovs_version: "2.8.90"
> root@ubuntu-24:~# uname -a
> Linux ubuntu-24 4.4.0-62-generic #83-Ubuntu SMP Wed Jan 18 14:10:15 UTC 2017 
> x86_64 x86_64 x86_64 GNU/Linux

Your image shows that libvirtd is calling into tc and hitting an error.
Then, something (probably libvirtd again) calls "ovs-vsctl del-port".
This therefore appears to be a problem in libvirtd; OVS is just doing
what it's told.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] test email for ovs discuss

[Nandan Kulkarni]

Hi there,
this is a test email for ovs discuss.

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

Re: [ovs-discuss] DPDK with UIO drivers is broken on Fedora since OVS 2.8.0

[Aaron Conole]

Hi Marcos,

Marcos Felipe Schwarz  writes:

> Thanks for the suggestion Aaron.
>
> Follows below the revised patch for the current master using Aaron and 
> Timothy contributions. May I submit the patch as is or are there any further 
> suggestions?
> I've tested it in the following conditions:
> 1) Fedora 27, ovs_user root:root, vfio-uio driver: Fixed by this patch
> 2) Fedora 27, ovs_user root:root, uio-pci-generic driver: Fixed by this patch
> 3) Fedora 27, ovs_user openvswitch:hugetlbfs, vfio-uio driver: Continues 
> working
> 4) Fedora 27, ovs_user openvswitch:hugetlbfs, uio-pci-generic driver: 
> Continues broken, for kernel 4.0 and newer since the user is missing the 
> CAP_SYS_ADMIN capability. Ref: 
> https://www.kernel.org/doc/Documentation/vm/pagemap.txt

Thanks for following up with this!  Please submit it as a patch.  I will
set aside time to review it (if Timothy doesn't beat me to it).

> diff --git a/lib/daemon-unix.c b/lib/daemon-unix.c
> index adb549c98..06528e9ab 100644
> --- a/lib/daemon-unix.c
> +++ b/lib/daemon-unix.c
> @@ -1047,5 +1047,6 @@ daemon_set_new_user(const char *user_spec)
>  }
>  }kernel
>  
> -switch_user = true;
> +if (!uid_verify(uid) || !gid_verify(gid))
> +switch_user = true;
>  }
> diff --git a/rhel/usr_lib_systemd_system_ovs-vswitchd.service.in 
> b/rhel/usr_lib_systemd_system_ovs-vswitchd.service.in
> index c6d9aa1b8..9b01c9271 100644
> --- a/rhel/usr_lib_systemd_system_ovs-vswitchd.service.in
> +++ b/rhel/usr_lib_systemd_system_ovs-vswitchd.service.in
> @@ -14,7 +14,7 @@ Environment=HOME=/var/run/openvswitch
>  EnvironmentFile=/etc/openvswitch/default.conf
>  EnvironmentFile=-/etc/sysconfig/openvswitch
>  @begin_dpdk@
> -ExecStartPre=-/usr/bin/chown :hugetlbfs /dev/hugepages
> +ExecStartPre=-/bin/sh -c '/usr/bin/chown :${OVS_USER_ID##*:} /dev/hugepages'
>  ExecStartPre=-/usr/bin/chmod 0775 /dev/hugepages
>  @end_dpdk@
>  ExecStart=/usr/share/openvswitch/scripts/ovs-ctl \
>
> Regards,
>
> Marcos Schwarz
>
> - Original Message -
> From: "Aaron Conole" 
> To: "Marcos Felipe Schwarz" 
> Cc: "Timothy Redaelli" , ovs-discuss@openvswitch.org
> Sent: Wednesday, January 10, 2018 6:54:24 PM
> Subject: Re: [ovs-discuss] DPDK with UIO drivers is broken on Fedora since 
> OVS 2.8.0
>
> Marcos Felipe Schwarz  writes:
>
>> Thanks for the suggestion Timothy, didn't knew that worked. Just
>> fixing some little things, it should be:
>> ExecStartPre=-/usr/bin/chown :${OVS_USER_ID##*:} /dev/hugepages
>>
>> Regarding the daemon-unix.c patch, any suggestions on how to improve
>> it? I tested it is working, but currently, I'm not aware if the new
>> capability should be set separeted as I did or using any of the
>> current blocks of code.
>
> One thing that might work is to not attempt switching users and
> capabilities if the current user is the target user.
>
> ex:
>
> @@ -1047,5 +1047,6 @@ daemon_set_new_user(const char *user_spec)
>  }
>  }
>  
> -switch_user = true;
> +if (!uid_verify(uid) || !gid_verify(gid))
> +switch_user = true;
>  }
>
> NOTE: this isn't compile or runtime tested, just a thought.
>
>> Regards,
>>
>> Marcos Schwarz
>>
>> - Original Message -
>> From: "Timothy Redaelli" 
>> To: "Marcos Felipe Schwarz" 
>> Cc: "Ben Pfaff" , ovs-discuss@openvswitch.org
>> Sent: Monday, January 8, 2018 9:20:17 AM
>> Subject: Re: [ovs-discuss] DPDK with UIO drivers is broken on Fedora
>> since OVS 2.8.0
>>
>> On Sat, Jan 6, 2018 at 2:41 AM, Marcos Felipe Schwarz
>>  wrote:
>>> Got it fixed.
>>>
>>> The problem was related to not setting the CAP_SYS_ADMIN capability at 
>>> daemon-unix.c. Follows the patch bellow to set the capability and 
>>> dynamically extract the group from OVS_USER_ID instead of forcing it to 
>>> :hugetlbfs.
>>>
>>> diff --git a/lib/daemon-unix.c b/lib/daemon-unix.c
>>> index 839114f3e..3b94164ea 100644
>>> --- a/lib/daemon-unix.c
>>> +++ b/lib/daemon-unix.c
>>> @@ -818,6 +818,9 @@ daemon_become_new_user_linux(bool access_datapath 
>>> OVS_UNUSED)
>>>  ret = capng_update(CAPNG_ADD, cap_sets, CAP_NET_ADMIN)
>>>|| capng_update(CAPNG_ADD, cap_sets, CAP_NET_RAW);
>>>  }
>>> +if (!ret) {
>>> +ret = capng_update(CAPNG_ADD, cap_sets, CAP_SYS_ADMIN);
>>> +}
>>>  } else {
>>>  ret = -1;
>>>  }
>>> diff --git a/rhel/usr_lib_systemd_system_ovs-vswitchd.service.in 
>>> b/rhel/usr_lib_systemd_system_ovs-vswitchd.service.in
>>> index c6d9aa1b8..94290a847 100644
>>> --- a/rhel/usr_lib_systemd_system_ovs-vswitchd.service.in
>>> +++ b/rhel/usr_lib_systemd_system_ovs-vswitchd.service.in
>>> @@ -14,7 +14,7 @@ Environment=HOME=/var/run/openvswitch
>>>  EnvironmentFile=/etc/openvswitch/default.conf
>>>  

Re: [ovs-discuss] DPDK with UIO drivers is broken on Fedora since OVS 2.8.0

[Marcos Felipe Schwarz]

Thanks for the suggestion Aaron.

Follows below the revised patch for the current master using Aaron and Timothy 
contributions. May I submit the patch as is or are there any further 
suggestions?
I've tested it in the following conditions:
1) Fedora 27, ovs_user root:root, vfio-uio driver: Fixed by this patch
2) Fedora 27, ovs_user root:root, uio-pci-generic driver: Fixed by this patch
3) Fedora 27, ovs_user openvswitch:hugetlbfs, vfio-uio driver: Continues working
4) Fedora 27, ovs_user openvswitch:hugetlbfs, uio-pci-generic driver: Continues 
broken, for kernel 4.0 and newer since the user is missing the CAP_SYS_ADMIN 
capability. Ref: https://www.kernel.org/doc/Documentation/vm/pagemap.txt

diff --git a/lib/daemon-unix.c b/lib/daemon-unix.c
index adb549c98..06528e9ab 100644
--- a/lib/daemon-unix.c
+++ b/lib/daemon-unix.c
@@ -1047,5 +1047,6 @@ daemon_set_new_user(const char *user_spec)
 }
 }kernel
 
-switch_user = true;
+if (!uid_verify(uid) || !gid_verify(gid))
+switch_user = true;
 }
diff --git a/rhel/usr_lib_systemd_system_ovs-vswitchd.service.in 
b/rhel/usr_lib_systemd_system_ovs-vswitchd.service.in
index c6d9aa1b8..9b01c9271 100644
--- a/rhel/usr_lib_systemd_system_ovs-vswitchd.service.in
+++ b/rhel/usr_lib_systemd_system_ovs-vswitchd.service.in
@@ -14,7 +14,7 @@ Environment=HOME=/var/run/openvswitch
 EnvironmentFile=/etc/openvswitch/default.conf
 EnvironmentFile=-/etc/sysconfig/openvswitch
 @begin_dpdk@
-ExecStartPre=-/usr/bin/chown :hugetlbfs /dev/hugepages
+ExecStartPre=-/bin/sh -c '/usr/bin/chown :${OVS_USER_ID##*:} /dev/hugepages'
 ExecStartPre=-/usr/bin/chmod 0775 /dev/hugepages
 @end_dpdk@
 ExecStart=/usr/share/openvswitch/scripts/ovs-ctl \

Regards,

Marcos Schwarz

- Original Message -
From: "Aaron Conole" 
To: "Marcos Felipe Schwarz" 
Cc: "Timothy Redaelli" , ovs-discuss@openvswitch.org
Sent: Wednesday, January 10, 2018 6:54:24 PM
Subject: Re: [ovs-discuss] DPDK with UIO drivers is broken on Fedora since OVS 
2.8.0

Marcos Felipe Schwarz  writes:

> Thanks for the suggestion Timothy, didn't knew that worked. Just
> fixing some little things, it should be:
> ExecStartPre=-/usr/bin/chown :${OVS_USER_ID##*:} /dev/hugepages
>
> Regarding the daemon-unix.c patch, any suggestions on how to improve
> it? I tested it is working, but currently, I'm not aware if the new
> capability should be set separeted as I did or using any of the
> current blocks of code.

One thing that might work is to not attempt switching users and
capabilities if the current user is the target user.

ex:

@@ -1047,5 +1047,6 @@ daemon_set_new_user(const char *user_spec)
 }
 }
 
-switch_user = true;
+if (!uid_verify(uid) || !gid_verify(gid))
+switch_user = true;
 }

NOTE: this isn't compile or runtime tested, just a thought.

> Regards,
>
> Marcos Schwarz
>
> - Original Message -
> From: "Timothy Redaelli" 
> To: "Marcos Felipe Schwarz" 
> Cc: "Ben Pfaff" , ovs-discuss@openvswitch.org
> Sent: Monday, January 8, 2018 9:20:17 AM
> Subject: Re: [ovs-discuss] DPDK with UIO drivers is broken on Fedora since 
> OVS 2.8.0
>
> On Sat, Jan 6, 2018 at 2:41 AM, Marcos Felipe Schwarz
>  wrote:
>> Got it fixed.
>>
>> The problem was related to not setting the CAP_SYS_ADMIN capability at 
>> daemon-unix.c. Follows the patch bellow to set the capability and 
>> dynamically extract the group from OVS_USER_ID instead of forcing it to 
>> :hugetlbfs.
>>
>> diff --git a/lib/daemon-unix.c b/lib/daemon-unix.c
>> index 839114f3e..3b94164ea 100644
>> --- a/lib/daemon-unix.c
>> +++ b/lib/daemon-unix.c
>> @@ -818,6 +818,9 @@ daemon_become_new_user_linux(bool access_datapath 
>> OVS_UNUSED)
>>  ret = capng_update(CAPNG_ADD, cap_sets, CAP_NET_ADMIN)
>>|| capng_update(CAPNG_ADD, cap_sets, CAP_NET_RAW);
>>  }
>> +if (!ret) {
>> +ret = capng_update(CAPNG_ADD, cap_sets, CAP_SYS_ADMIN);
>> +}
>>  } else {
>>  ret = -1;
>>  }
>> diff --git a/rhel/usr_lib_systemd_system_ovs-vswitchd.service.in 
>> b/rhel/usr_lib_systemd_system_ovs-vswitchd.service.in
>> index c6d9aa1b8..94290a847 100644
>> --- a/rhel/usr_lib_systemd_system_ovs-vswitchd.service.in
>> +++ b/rhel/usr_lib_systemd_system_ovs-vswitchd.service.in
>> @@ -14,7 +14,7 @@ Environment=HOME=/var/run/openvswitch
>>  EnvironmentFile=/etc/openvswitch/default.conf
>>  EnvironmentFile=-/etc/sysconfig/openvswitch
>>  @begin_dpdk@
>> -ExecStartPre=-/usr/bin/chown :hugetlbfs /dev/hugepages
>> +ExecStartPre=-/bin/sh -c 'chown :$(echo $OVS_USER_ID | tr ":" "\n" | tail 
>> -1) /dev/hugepages'
>
> I think it's better to avoid using multiple useless forks, shell
> script parameter expansion are better in this case:
>
> ExecStartPre=-/bin/sh -c '/usr/bin/chown 

Re: [ovs-discuss] ONIE installer for OVS

[Scott Reeve]

Here's a good starting point:

http://www.opencompute.org/wiki/Networking/ONIE/NOS_Status

I don't see OVS specifically, but it could be that some of the NOSes have
OVS built in or can be easily installed on top.



On Mon, Jan 22, 2018 at 2:34 PM, Shivaram Mysore 
wrote:

> Hi,
> Is there a ONIE installer for OVS?
>
> Thanks
>
> ___
> 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-dev] mbuf pool sizing

[Kevin Traynor]

On 01/17/2018 07:48 PM, Venkatesan Pradeep wrote:
> Hi,
> 
> Assuming that all ports use the same MTU,  in OVS2.8 and earlier, a single 
> mempool of 256K buffers (MAX_NB_MBUF = 4096 * 64) will be created and shared 
> by all the ports
> 
> With the OVS2.9 mempool patches, we have port specific allocation and the 
> number of mbufs created for each port is based on the following formula (with 
> a lower limit of MIN_NB_MBUF = 4096*4)
>n_mbufs = dev->requested_n_rxq * dev->requested_rxq_size
>   + dev->requested_n_txq * dev->requested_txq_size
>   + MIN(RTE_MAX_LCORE, dev->requested_n_rxq) * NETDEV_MAX_BURST
>   + MIN_NB_MBUF;
> 
> Using minimal value (1) for n_rxq and n_rxq and default value (2048) for 
> requested_rxq_size and requested_txq_size, the above translates to
>   n_mbufs = 1*2048 + 1*2048 + 1*32 + 4096*4  = 20512
> 
> Assuming all ports have the same MTU, this means that approximately 13 ports 
> in OVS2.9 will consume as much memory as the single mempool shared by all 
> ports in OVS2.8 (256*1024 / 20512) .
> 
> When a node is upgraded from OVS2.8 to OVS2.9 it is quite possible that the 
> memory set aside for OVS may be insufficient. I'm not sure if this aspect has 
> been discussed previously and wanted to bring this up for discussion.
> 

Hi Pradeep, I don't think it has been discussed. I guess the thinking
was that with a giant shared mempool, it was over provisioning when
there was a few ports, and in the case where there was a lot of ports
there could be some starvation at run time. It also meant if you had a
mix of different MTU's you had multiple giant shared mempools and could
run out of memory very quickly at config or run time then also.

So I can see the argument for having a mempool per port, as it is more
fine grained and if you are going to run short of memory, it will at
least be at config time. The problem is if you give some over provision
to each port and you have a lot of ports, you hit the situation you are
seeing.

I think some amount of over provision per port is needed because you
don't want to be cutting it so fine that you run into memory issues at
run time about local mbuf caches on cores running out, or even if
someone used dpdk rings to send the mbuf somewhere else for a time.
There may be other corner cases too. Perhaps as compromise the min size
could be reduce from 4096*4 to 4096*2 or 4096.

Thoughts?

Kevin.

> Regards,
> 
> Pradeep
> 
> 
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
> 

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