Re: [ovs-dev] [PATCH v4 0/6] Add minimum network namespace support.

[Flavio Leitner]

On Tue, Apr 03, 2018 at 09:48:55PM -0300, Flavio Leitner wrote:
> On Sat, Mar 31, 2018 at 01:23:20PM -0700, Ben Pfaff wrote:
> > On Thu, Mar 29, 2018 at 11:05:25PM -0300, Flavio Leitner wrote:
> > > Today Open vSwitch doesn't know about network namespaces (netns), but
> > > users are moving internal ports to other namespaces.  Although packets
> > > are still flowing, the daemon fails to find out basic port information,
> > > like if it is UP or DOWN, for instance.
> > > 
> > > This patchset rely on a new kernel vport API recently accepted to find
> > > out the new network namespace ID of a bridge's port. This information
> > > along with the port's name recorded in the database is used to match the
> > > corresponding netlink messages.
> > > 
> > > This patchset also leverages another kernel API that allows the daemon
> > > to listen to all netlink messages from all netns which has an ID assigned
> > > into it.  This and the previous change allows the userspace to track ports
> > > in other network namespaces.
> > > 
> > > If any of the APIs aren't available, it falls back to the older APIs to
> > > not break backwards compatibility.
> > 
> > I applied this to master.  Thank you!
> > 
> > I have a request: please submit a patch to add something to NEWS to
> > explain the new features.
> 
> Will do.

I sent out a patch:
https://mail.openvswitch.org/pipermail/ovs-dev/2018-April/345973.html
Thanks,
fbl

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

[ovs-dev] [PATCH] netns: Add documentation and update NEWS.

[Flavio Leitner]

Create a document to describe the how it works and known
limitations and update the NEWS accordingly.

Signed-off-by: Flavio Leitner 
---
 Documentation/topics/networking-namespaces.rst | 69 ++
 NEWS   |  1 +
 2 files changed, 70 insertions(+)
 create mode 100644 Documentation/topics/networking-namespaces.rst

diff --git a/Documentation/topics/networking-namespaces.rst 
b/Documentation/topics/networking-namespaces.rst
new file mode 100644
index 0..96589b513
--- /dev/null
+++ b/Documentation/topics/networking-namespaces.rst
@@ -0,0 +1,69 @@
+..
+  Licensed under the Apache License, Version 2.0 (the "License"); you may
+  not use this file except in compliance with the License. You may obtain
+  a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing, software
+  distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
+  WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+  License for the specific language governing permissions and limitations
+  under the License.
+
+  Convention for heading levels in Open vSwitch documentation:
+
+  ===  Heading 0 (reserved for the title in a document)
+  ---  Heading 1
+  ~~~  Heading 2
+  +++  Heading 3
+  '''  Heading 4
+
+  Avoid deeper levels because they do not render well.
+
+===
+Open vSwitch Networking Namespaces on Linux
+===
+
+The Open vSwitch has networking namespaces basic support on Linux. That allows
+ovs-vswitchd daemon to continue tracking status and statistics after moving a
+port to another networking namespace.
+
+
+How It Works
+
+
+The daemon ovs-vswitchd runs on what is called parent network namespace. It
+listens to netlink event messages from all networking namespaces (netns)
+with an identifier on the parent. Each netlink message contains the network
+namespace identifier (netnsid) as ancillary data which is used to match the
+event to the corresponding port.
+
+The ovs-vswitchd uses an extended openvswitch kernel API [1]_ to get the
+current netnsid (stored in struct netdev_linux) and statistics from a specific
+port.  The netnsid remains cached in userspace until a changing event is
+received, for example, when the port is moved to another network namespace.
+
+Using another extended kernel API [2]_, the daemon gets port's information
+such as flags, MTU, MAC address and ifindex from a port already in another
+namespace.
+
+The upstream kernel 4.15 includes the necessary changes for the basic support.
+In case of the running kernel doesn't provide the APIs, the daemon falls back
+to the previous behavior.
+
+.. [1] Request cmd: OVS_VPORT_CMD_GET, attribute: OVS_VPORT_ATTR_NETNSID
+.. [2] Request cmd: RTM_GETLINK passing IFLA_IF_NETNSID attribute.
+
+
+Limitations
+---
+
+Currently it is only possible to retrieve the information listed in the
+above section.  Most of other operations, for example querying MII or
+setting MTU, lacks the proper API in the kernel, so they remain unsupported.
+
+In most use cases that needs to move ports to another networking namespaces
+should use veth pairs instead because it offers a cleaner and more robust
+solution with no noticeable performance penalty.
+
diff --git a/NEWS b/NEWS
index 757d648a1..83fbe6038 100644
--- a/NEWS
+++ b/NEWS
@@ -6,6 +6,7 @@ Post-v2.9.0
"table#".  These are not helpful names for the purpose of accepting
and displaying table names, so now tables by default have no names.
  * The "null" interface type, deprecated since 2013, has been removed.
+ * Add minimum network namespace support for Linux.
- ovs-ofctl:
  * ovs-ofctl now accepts and display table names in place of numbers.  By
default it always accepts names and in interactive use it displays them;
-- 
2.14.3


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

Re: [ovs-dev] [RFC] [PATCH] 1/1 Add multi-column index support for the Python IDL

[Terry Wilson]

On Wed, Apr 11, 2018 at 12:52 PM, Flavio Leitner  wrote:
> On Wed, Apr 11, 2018 at 07:23:07PM +0200, Timothy Redaelli wrote:
>> On Tue, 10 Apr 2018 15:20:54 -0700
>> Ben Pfaff  wrote:
>>
>> > On Mon, Apr 09, 2018 at 03:03:03PM -0500, twil...@redhat.com wrote:
>> > > From: Terry Wilson 
>> > >
>> > > This adds multi-column index support for the Python IDL that is
>> > > similar to the feature in the C IDL.
>> > >
>> > > Signed-off-by: Terry Wilson 
>> >
>> > Thanks for working on this.
>> >
>> > I think that this adds a new Python module dependency on
>> > "sortedcontainers".  I didn't have it installed for python2 or
>> > python3--at least on Debian, it is not installed by default--so many
>> > tests failed.  I guess that we should at least document that, and
>> > probably it means that there should be new dependencies.
>> >
>> > (When I installed the Python module, everything was fine.)
>>
>> Hi,
>> unfortunately "python-sortedcontainers" packages are not available on
>> RHEL repositories.
>>
>> This means, if this commit is approved, it will not be possible to build
>> OVS on RHEL anymore and, if we skip the tests, it will not be possible
>> to use the python OVS extensions.
>>
>> so I suggest, if possible, to find and alternative to
>> "sortedcontainers".
>
> Hi Terry,
>
> Not trying to be the obstructionist here, but as you pointed out in
> the cover letter and Tim highlighted here, that dependency isn't
> packaged in neither RHEL (7 or 8) or EPEL, which means it breaks OVS
> backwards compatibility. I suspect others not-so-recent distros might
> have the same problem.  For instance, only F27 includes that IIRC.
>
> Do you have a plan to address that issue?

My plan, if people are in general OK with adding the dependency at all
(and the architecture of the RFC patch), is 1) Take the Fedora
packages and try to get them in RHEL and 2) make only the feature
dependent on sortedcontainers with some simple try/except magic.
Another option would be to just take the part of sortedcontainers
(which is Apache 2.0) that we need, drop it in the tree, and have the
exception on import actually import from the local copy. In general I
don't like copying projects into other projects, though.
sortedcontainers is a very mature, fast, pure-python library. It would
be handy to be able to use it even in other parts of the library. For
instance, we call sorted() a lot in data.py for doing things like
to_json(), to_python(), to_string(), etc. Sorting on each call instead
of storing in a sorted object in the first place. And those methods
are called *a lot*.

Terry
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 3/3] rhel: add "force-reload-kmod" support in "ovs-systemd-reload"

[Guru Shetty]

On 11 April 2018 at 11:03, Timothy Redaelli  wrote:

> On Wed, 11 Apr 2018 10:05:53 -0700
> Guru Shetty  wrote:
>
> > On 22 December 2017 at 07:00, Timothy Redaelli 
> > wrote:
> >
> > > Since you can't use "ovs-ctl force-reload-kmod" on Fedora/RHEL, due
> > > to systemd dependencies, this commit adds the "force-reload-kmod"
> > > feature on ovs-systemd-reload.
> > >
> > > Signed-off-by: Timothy Redaelli 
> > >
> >
> > Tim/Aaron,
> >   We have some confusion with this. So, how do we invoke this with
> > systemd? I guess, it is not supposed to be invoked with "service
> > openvswitch reload", right? And why can't we use "ovs-ctl
> > force-reload-kmod" with Fedora/RHEL?
>
> Hi,
> because on Fedora/RHEL we use systemd dependencies and so we have 3
> (main) service files: openvswitch.spec, ovs-vswitchd.spec and
> ovsdb-server.spec that are interconnected (see rhel/README.RHEL.rst).
>
> If you use ovs-ctl directly systemd will loose tracks of the new
> ovsdb-server and ovs-vswitchd processes and so you can't restart it by
> using "systemctl restart".
>
> Moreover it seems ovs-vswitchd is not restarted correctly in this case.
>

Okay. So, what is the correct way to call force-reload-kmod?
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] Atención al cliente

[Axiomas y errores en la comunicación]

 

 
 
 
Atención al cliente interno como estrategia 
Abril 19 - webinar Interactivo

Objetivo:

Tu deber es mantener una relación apropiada con ellos y ofrecerles programas de 
formación constantemente. No basta solo con recompensar su esfuerzo con mejoras 
económicas sino que debes procurar que tus empleados se sientan felices de 
pertenecer a tu organización. 

Temario:

-Necesidades del cliente interno..
-Diferencia entre atención y servicio al cliente. 
-Selección, socialización, formación y desarrollo del cliente interno. 
-Axiomas y errores en la comunicación.
 
 
Temario e Inscripciones:

Respondiendo por este medio "Cliente"+TELÉFONO + NOMBRE o marcando al:

045 + 5515546630 
 

 


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

Re: [ovs-dev] [PATCH v1] tests: Added NSH related unit test cases for datapath

[Ashish Varma]

Sure, no problem.

Thanks,
Ashish

On Tue, Apr 10, 2018 at 5:00 PM, Gregory Rose  wrote:

> On 4/6/2018 7:35 AM, Gregory Rose wrote:
>
>>
>>
>> On 4/4/2018 10:23 AM, Ben Pfaff wrote:
>>
>>> On Thu, Mar 29, 2018 at 04:46:09PM -0700, Ashish Varma wrote:
>>>
 Added test cases for encap, decap, replace and forwarding of NSH
 packets.
 Also added a python script 'sendpkt.py' to send hex ethernet frames.

 Signed-off-by: Ashish Varma 

>>> Ashish, do you have a suggestion who should review this?  Greg, are you
>>> the right person?
>>>
>> I can have a look at them now that I'm back but need to get caught up
>> with some other issues first.
>>
>
> Ashish,
>
> I continue to be otherwise occupied so I'm sorry for the delay in
> reviewing your patch.  It is still on my radar!
>
> Thanks,
>
> - Greg
>
>
>> Thanks,
>>
>> - Greg
>>
>
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 3/3] rhel: add "force-reload-kmod" support in "ovs-systemd-reload"

[Timothy Redaelli]

On Wed, 11 Apr 2018 10:05:53 -0700
Guru Shetty  wrote:

> On 22 December 2017 at 07:00, Timothy Redaelli 
> wrote:
> 
> > Since you can't use "ovs-ctl force-reload-kmod" on Fedora/RHEL, due
> > to systemd dependencies, this commit adds the "force-reload-kmod"
> > feature on ovs-systemd-reload.
> >
> > Signed-off-by: Timothy Redaelli 
> >  
> 
> Tim/Aaron,
>   We have some confusion with this. So, how do we invoke this with
> systemd? I guess, it is not supposed to be invoked with "service
> openvswitch reload", right? And why can't we use "ovs-ctl
> force-reload-kmod" with Fedora/RHEL?

Hi,
because on Fedora/RHEL we use systemd dependencies and so we have 3
(main) service files: openvswitch.spec, ovs-vswitchd.spec and
ovsdb-server.spec that are interconnected (see rhel/README.RHEL.rst).

If you use ovs-ctl directly systemd will loose tracks of the new
ovsdb-server and ovs-vswitchd processes and so you can't restart it by
using "systemctl restart".

Moreover it seems ovs-vswitchd is not restarted correctly in this case.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [RFC] [PATCH] 1/1 Add multi-column index support for the Python IDL

[Ben Pfaff]

On Wed, Apr 11, 2018 at 02:52:51PM -0300, Flavio Leitner wrote:
> On Wed, Apr 11, 2018 at 07:23:07PM +0200, Timothy Redaelli wrote:
> > On Tue, 10 Apr 2018 15:20:54 -0700
> > Ben Pfaff  wrote:
> > 
> > > On Mon, Apr 09, 2018 at 03:03:03PM -0500, twil...@redhat.com wrote:
> > > > From: Terry Wilson 
> > > > 
> > > > This adds multi-column index support for the Python IDL that is
> > > > similar to the feature in the C IDL.
> > > > 
> > > > Signed-off-by: Terry Wilson   
> > > 
> > > Thanks for working on this.
> > > 
> > > I think that this adds a new Python module dependency on
> > > "sortedcontainers".  I didn't have it installed for python2 or
> > > python3--at least on Debian, it is not installed by default--so many
> > > tests failed.  I guess that we should at least document that, and
> > > probably it means that there should be new dependencies.
> > > 
> > > (When I installed the Python module, everything was fine.)
> > 
> > Hi,
> > unfortunately "python-sortedcontainers" packages are not available on
> > RHEL repositories.
> > 
> > This means, if this commit is approved, it will not be possible to build
> > OVS on RHEL anymore and, if we skip the tests, it will not be possible
> > to use the python OVS extensions.
> > 
> > so I suggest, if possible, to find and alternative to
> > "sortedcontainers".
> 
> Hi Terry,
> 
> Not trying to be the obstructionist here, but as you pointed out in
> the cover letter and Tim highlighted here, that dependency isn't
> packaged in neither RHEL (7 or 8) or EPEL, which means it breaks OVS
> backwards compatibility. I suspect others not-so-recent distros might
> have the same problem.  For instance, only F27 includes that IIRC.
> 
> Do you have a plan to address that issue?

We used to install some Python compatibility modules on some OSes.  See
commit e23812fc60af (Increase prerequisite from Python 2.4 to Python
2.7.) to see how we did it before (which was pretty simple).  The same
thing might work here.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

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

[Kevin Traynor]

On 04/10/2018 11:12 AM, Stokes, Ian wrote:
 -Original Message-
 From: Ilya Maximets [mailto:i.maxim...@samsung.com]
 Sent: Monday, 29 January, 2018 09:35
 To: Jan Scheurich ; Venkatesan Pradeep
 ; Stokes, Ian
 ; d...@openvswitch.org
 Cc: Kevin Traynor ; Flavio Leitner
 ; Loftus, Ciara ; Kavanagh,
 Mark B ; Ben Pfaff (b...@ovn.org)
 ; acon...@redhat.com; disc...@openvswitch.org
 Subject: Re: Mempool issue for OVS 2.9

 On 29.01.2018 11:19, Jan Scheurich wrote:
> Hi,
>
> I'd like to take one step back and look at how much many mbufs we
>> actually need.
>
> Today mbufs are consumed in the following places:
>
>  1. Rx queues of **physical** dpdk ports: dev->requested_n_rxq * dev-
>>> requested_rxq_size
> Note 1: These mbufs are hogged up at all times.
> Note 2: There is little point in configuring more rx queues per
>> phy port than there are PMDs to poll them.
> Note 3: The rx queues of vhostuser ports exist as virtqueues in
>> the guest and do not hog mbufs.
>  2. One batch per PMD during processing: #PMD * NETDEV_MAX_BURST  3.
> One batch per tx queue with time-based tx batching:
> dev->requested_n_txq * NETDEV_MAX_BURST  4. Tx queues of **physical**
>> ports: dev->requested_n_txq * expected peak tx queue fill level
> Note 1:  The maximum of 2K mbufs per tx queue can only be reached
>> if the OVS transmit rate exceeds the line rate for a long time.
 This can only happen for large packets and when the traffic
 originates from VMs on the compute node. This would be a case of
 under- dimensioning and packets would be dropped in any case. Excluding
>> that scenario, a typical peak tx queue fill level would be when all PMDs
>> transmit a full batch at the same time: #PMDs * NETDEV_MAX_BURST.

 Above assumption is wrong. Just look at ixgbe driver:
 drivers/net/ixgbe/ixgbe_rxtx.c: tx_xmit_pkts():

/*
 * Begin scanning the H/W ring for done descriptors when the
 * number of available descriptors drops below tx_free_thresh.
>> For
 * each done descriptor, free the associated buffer.
 */
if (txq->nb_tx_free < txq->tx_free_thresh)
┊   ixgbe_tx_free_bufs(txq);

 The default value for 'tx_free_thresh' is 32. So, if I'll configure
 number of TX descriptors to 4096, driver will start to free mbufs
 only when it will have more than 4063 mbufs inside its TX queue. No
 matter how frequent calls to send() function.
>>>
>>> OK, but that doesn't change my general argument. The mbufs hogged in the
>> tx side of the phy port driver are coming from all ports (least likely the
>> port itself). Considering them in dimensioning the port's private mempool
>> is conceptually wrong. In my simplified dimensioning formula below I have
>> already assumed full occupancy of the tx queue for phy ports. The second
>> key observation is that vhostuser ports do not hog mbufs at all. And vhost
>> zero copy doesn't change that.
>>
>> Formula below maybe good for static environment. I want to change number
>> of PMD threads dynamically in my deployments and this working in current
>> per-port model and with oversized shared pool. If we'll try to reduce
>> memory consumption of the shared pool we'll have to reconfigure all the
>> devices each time we change the number of PMD threads. This would be
>> really bad.
>> So, size of the memory pool should not depend on dynamic characteristics
>> of the datapath or other ports to avoid unexpected interrupts in traffic
>> flows in case of random changes in configuration. Of course, it could
>> depend on characteristics of the port itself in case of per-port model. In
>> case of shared mempool model the size should only depend on static
>> datapath configuration.
> 
> Hi all,
> 
> Now seems a good time to kick start this conversation again as there's a few 
> patches floating around for mempools on master and 2.9.
> I'm happy to work on a solution for this but before starting I'd like to 
> agree on the requirements so we're all comfortable with the solution.
> 

Thanks for kicking it off Ian. FWIW, the freeing fix code can work with
both schemes below. I already have that between the patches for
different branches. It should be straightforward to change to cover both
in same code. I can help with that if needed.

> I see two use cases above, static and dynamic. Each have their own 
> requirements (I'm keeping OVS 2.10 in mind here as it's an issue we need to 
> resolve).
> 
> Static environment
> 1. For a given deployment, the 2.10 the mempool design should use the same or 
> less memory as the shared mempool design of 2.9.
> 2. Memory pool size can depend on 

Re: [ovs-dev] [RFC] [PATCH] 1/1 Add multi-column index support for the Python IDL

[Flavio Leitner]

On Wed, Apr 11, 2018 at 07:23:07PM +0200, Timothy Redaelli wrote:
> On Tue, 10 Apr 2018 15:20:54 -0700
> Ben Pfaff  wrote:
> 
> > On Mon, Apr 09, 2018 at 03:03:03PM -0500, twil...@redhat.com wrote:
> > > From: Terry Wilson 
> > > 
> > > This adds multi-column index support for the Python IDL that is
> > > similar to the feature in the C IDL.
> > > 
> > > Signed-off-by: Terry Wilson   
> > 
> > Thanks for working on this.
> > 
> > I think that this adds a new Python module dependency on
> > "sortedcontainers".  I didn't have it installed for python2 or
> > python3--at least on Debian, it is not installed by default--so many
> > tests failed.  I guess that we should at least document that, and
> > probably it means that there should be new dependencies.
> > 
> > (When I installed the Python module, everything was fine.)
> 
> Hi,
> unfortunately "python-sortedcontainers" packages are not available on
> RHEL repositories.
> 
> This means, if this commit is approved, it will not be possible to build
> OVS on RHEL anymore and, if we skip the tests, it will not be possible
> to use the python OVS extensions.
> 
> so I suggest, if possible, to find and alternative to
> "sortedcontainers".

Hi Terry,

Not trying to be the obstructionist here, but as you pointed out in
the cover letter and Tim highlighted here, that dependency isn't
packaged in neither RHEL (7 or 8) or EPEL, which means it breaks OVS
backwards compatibility. I suspect others not-so-recent distros might
have the same problem.  For instance, only F27 includes that IIRC.

Do you have a plan to address that issue?

-- 
Flavio

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

Re: [ovs-dev] [PATCH v10 3/3] dpif-netdev: Detection and logging of suspicious PMD iterations

[Jan Scheurich]

Hi Ilya,

I would not say this is expected behavior.

It seems that you are executing on a somewhat slower system (tsc clock seems to 
be 100/us = 0.1 GHz) and that, even with only 5 lines logged before and after,  
the logging output is causing so much slow down of the PMD that it continues to 
cause iterations using excessive cycles (362000 = 3.62 ms!) due to logging.

The actual iteration with logging is not flagged as suspicious, but the 
subsequent iteration gets the hit of the massive cycles that have passed on the 
TSC clock. The "phantom" duration of 0 us shown is probably a side effect of 
this. 

I will try to reproduce and investigate. I will have a look at the detection 
logic to see if this can be avoided.

BR, Jan


> -Original Message-
> From: Ilya Maximets [mailto:i.maxim...@samsung.com]
> Sent: Tuesday, 27 March, 2018 16:05
> To: Jan Scheurich ; d...@openvswitch.org
> Cc: ktray...@redhat.com; ian.sto...@intel.com; billy.o.mah...@intel.com
> Subject: Re: [PATCH v10 3/3] dpif-netdev: Detection and logging of suspicious 
> PMD iterations
> 
> I see following behaviour:
> 
> 1. Configure low -us (like 100)
> 2. After that I see many logs about suspicious iterations (expected).
> 
> 2018-03-27T13:58:27Z|03574|pmd_perf(pmd7)|WARN|Suspicious iteration 
> (Excessive total cycles): tsc=520415762246435
> duration=106 us
> 2018-03-27T13:58:27Z|03575|pmd_perf(pmd7)|WARN|Neighborhood of suspicious 
> iteration:
>tsc cycles   packets  cycles/pkt   pkts/batch   
> vhost qlen   upcalls  cycles/upcall
>520415762297985 9711 32   303  32   
> 424  00
>520415762287041 1066732   333  32   
> 419  00
>520415762277319 9722 32   303  32   
> 429  00
>520415762267083 9971 32   311  32   
> 443  00
>520415762257413 9670 32   302  32   
> 451  00
>520415762246435 1069932   334  32   
> 448  00
>520415762235033 1110932   347  32   
> 455  00
>520415762180220 9826 32   307  32   
> 399  00
>520415762169792 1022932   319  32   
> 413  00
>520415762160385 9407 32   293  32   
> 408  00
>520415762150221 9891 32   309  32   
> 434  00
> 2018-03-27T13:58:27Z|03576|pmd_perf(pmd7)|WARN|Suspicious iteration 
> (Excessive total cycles): tsc=520415762469997
> duration=104 us
> 2018-03-27T13:58:27Z|03577|pmd_perf(pmd7)|WARN|Neighborhood of suspicious 
> iteration:
>tsc cycles   packets  cycles/pkt   pkts/batch   
> vhost qlen   upcalls  cycles/upcall
>520415762519119 9462 32   295  32   
> 505  00
>520415762509595 9319 32   291  32   
> 537  00
>520415762500154 9283 32   290  32   
> 569  00
>520415762490585 9287 32   290  32   
> 601  00
>520415762480693 9730 32   304  32   
> 633  00
>520415762469997 1041432   325  32   
> 665  00
>520415762459348 1034232   323  32   
> 697  00
>520415762297985 9711 32   303  32   
> 424  00
>520415762287041 1066732   333  32   
> 419  00
>520415762277319 9722 32   303  32   
> 429  00
>520415762267083 9971 32   311  32   
> 443  00
> 
> 3. Configure back high -us (like 1000).
> 4. Logs are still there with zero duration. Logs printed every second like 
> this:
> 
> 2018-03-27T14:02:08Z|04140|pmd_perf(pmd7)|WARN|Suspicious iteration 
> (Excessive total cycles): tsc=520437806368099 duration=0
> us
> [Thread 0x7fb56f2910 (LWP 19754) exited]
> [New Thread 0x7fb56f2910 (LWP 19755)]
> 2018-03-27T14:02:08Z|04141|pmd_perf(pmd7)|WARN|Neighborhood of suspicious 
> iteration:
>tsc cycles   packets  cycles/pkt   pkts/batch   
> vhost qlen   upcalls  cycles/upcall
>520437806368309 44   0000  
>   00
>

[ovs-dev] Pricelist April 2018

[Bonesca Mailing]

Deze email nieuwsbrief werd in grafisch HTML formaat verzonden.
Als u deze tekstversie ziet, verkiest uw email programma "gewone tekst" emails.
U kan de originele nieuwsbrief online bekijken:
http://ymlpsend3.com/z6bv36



GB:  In the attachment you can find our latest pricelist!
DE: Im Anlage finden sie unsere Aktuelle Preisliste!
NL: In de bijlage vind u onze meest recente prijslijst!
FR: Dans l'attachement vous pouvez trouver notre liste des prix
nouveau!
ES: En archivo adjunto encontrará nuestro listado de presios!

We again reduced all prices of shrimps, please check our prices
carefully.

TO CELEBRATE Bengal Newyear, Aluth Avurudda, Songkran and
Pi Mai 13 & 14 April we have following special promotion :

Every 2 box shrimps (any type) you buy you get 1 box tilapia 800+ for
FREE!!!

Our offer online and for more offers click here (
http://bonesca.mamutweb.com/subdet1.htm )

Kind regards, Mit freundlichen Grüssen, Cordialement, Saludos,

Salesteam Bonesca

ne...@bonesca.nl - sales, Dutch, Arab, English, German
maria...@bonesca.nl - sales, Dutch, French, English, German
t...@bonesca.nl - sales, Vietnamese, Thai, Laothioan, German, English
r...@bonesca.nl - sales, Tamil, Dutch, English
poli...@bonesca.nl - sales: Spanish, French, Portuguese, English
corne...@bonesca.nl - office support
ber...@bonesca.nl - purchase/sales, Dutch, German, English

Bonesca Import en Export BV

Schulpengat 9
8321 WC URK
Netherlands
Tel.: +31 (0) 527 70 10 63
Fax: +31 (0) 527 69 04 46
Mail: i...@bonesca.nl
Web: www.bonesca.nl

_
Sign out / Change E-mailadress: 
http://ymlpsend3.com/ughbywyjgsgubbebbgjmebgghewbs
Powered door YourMailingListProvider

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

Re: [ovs-dev] [RFC] [PATCH] 1/1 Add multi-column index support for the Python IDL

[Timothy Redaelli]

On Tue, 10 Apr 2018 15:20:54 -0700
Ben Pfaff  wrote:

> On Mon, Apr 09, 2018 at 03:03:03PM -0500, twil...@redhat.com wrote:
> > From: Terry Wilson 
> > 
> > This adds multi-column index support for the Python IDL that is
> > similar to the feature in the C IDL.
> > 
> > Signed-off-by: Terry Wilson   
> 
> Thanks for working on this.
> 
> I think that this adds a new Python module dependency on
> "sortedcontainers".  I didn't have it installed for python2 or
> python3--at least on Debian, it is not installed by default--so many
> tests failed.  I guess that we should at least document that, and
> probably it means that there should be new dependencies.
> 
> (When I installed the Python module, everything was fine.)

Hi,
unfortunately "python-sortedcontainers" packages are not available on
RHEL repositories.

This means, if this commit is approved, it will not be possible to build
OVS on RHEL anymore and, if we skip the tests, it will not be possible
to use the python OVS extensions.

so I suggest, if possible, to find and alternative to
"sortedcontainers".

Thank you

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



-- 
Timothy Redaelli
Software Engineer
Red Hat Italia
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 3/3] rhel: add "force-reload-kmod" support in "ovs-systemd-reload"

[Guru Shetty]

On 22 December 2017 at 07:00, Timothy Redaelli  wrote:

> Since you can't use "ovs-ctl force-reload-kmod" on Fedora/RHEL, due to
> systemd dependencies, this commit adds the "force-reload-kmod" feature on
> ovs-systemd-reload.
>
> Signed-off-by: Timothy Redaelli 
>

Tim/Aaron,
  We have some confusion with this. So, how do we invoke this with systemd?
I guess, it is not supposed to be invoked with "service openvswitch
reload", right? And why can't we use "ovs-ctl force-reload-kmod" with
Fedora/RHEL?


> ---
>  rhel/usr_share_openvswitch_scripts_ovs-systemd-reload | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/rhel/usr_share_openvswitch_scripts_ovs-systemd-reload
> b/rhel/usr_share_openvswitch_scripts_ovs-systemd-reload
> index 5d2efc621..894df0427 100755
> --- a/rhel/usr_share_openvswitch_scripts_ovs-systemd-reload
> +++ b/rhel/usr_share_openvswitch_scripts_ovs-systemd-reload
> @@ -40,6 +40,10 @@ add_managers() {
>  :
>  }
>
> -restart
> +if [ "$1" = "force-reload-kmod" ]; then
> +force_reload_kmod
> +else
> +restart
> +fi
>
>  exit 0
> --
> 2.14.3
>
> ___
> 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

Re: [ovs-dev] [PATCH v1] Fix AUTHORS.rst

[Ben Pfaff]

On Wed, Apr 11, 2018 at 10:30:17AM +0100, lucasago...@gmail.com wrote:
> From: Lucas Alvares Gomes 
> 
> The commit 9afc6f14ee7b2622703d98689acb0044d4a5492e added a new author
> which name was too long that broke the column size. Runinng "make
> docs-checks" was failing because of that.
> 
> All this patch does is to enlarge the "Name" column to fit the new
> author's name.
> 
> Signed-off-by: Lucas Alvares Gomes 

Thanks, applied to master.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [RFC 0/2] dpdk: minor refactor of the initialization step

[Mooney, Sean K]

> -Original Message-
> From: Kevin Traynor [mailto:ktray...@redhat.com]
> Sent: Wednesday, April 11, 2018 4:03 PM
> To: Aaron Conole ; Mooney, Sean K
> 
> Cc: d...@openvswitch.org; Ilya Maximets ; Assaf
> Muller 
> Subject: Re: [ovs-dev] [RFC 0/2] dpdk: minor refactor of the
> initialization step
> 
> On 04/11/2018 02:21 PM, Aaron Conole wrote:
> > "Mooney, Sean K"  writes:
> >
> >>> -Original Message-
> >>> From: Aaron Conole [mailto:acon...@redhat.com]
> >>> Sent: Monday, April 9, 2018 4:32 PM
> >>> To: Mooney, Sean K 
> >>> Cc: d...@openvswitch.org; Stokes, Ian ; Kevin
> >>> Traynor ; Ilya Maximets
> >>> ; Loftus, Ciara ;
> >>> Terry Wilson ; Assaf Muller 
> >>> Subject: Re: [RFC 0/2] dpdk: minor refactor of the initialization
> >>> step
> >>>
> >>> "Mooney, Sean K"  writes:
> >>>
>  So just from a deployment tools point of view I would like to
> point
>  out that This change could break existing workflow that deploy ovs
>  in
> >>> a docker container.
>  Kolla ansible assumes that if the docker ovs_vswitchd container is
>  still running that the is infact running in dpdk mode when we set
>  dpdk-init=true.
> >>>
> >>> Is there a way to test this out and see the behavior?
> >> [Mooney, Sean K] well you could use kolla to deploy ovs-dpdk :) Am
> >> when I wrote the code I relied on the existing behavior.
> >> when kolla ansible is deploying openstack we first deploy the ovsdb.
> >> https://github.com/openstack/kolla-
> ansible/blob/4c39ea7eccd9467757226
> >> 46eec19f9ea5cbe6eb5/ansible/roles/ovs-dpdk/handlers/main.yml#L2-L37
> >> Then we start the ovs-vswitchd container
> >> https://github.com/openstack/kolla-
> ansible/blob/4c39ea7eccd9467757226
> >> 46eec19f9ea5cbe6eb5/ansible/roles/ovs-dpdk/handlers/main.yml#L55-L73
> >> finally we configure the bridges and physical interfaces.
> >> https://github.com/openstack/kolla-
> ansible/blob/4c39ea7eccd9467757226
> >> 46eec19f9ea5cbe6eb5/ansible/roles/ovs-dpdk/handlers/main.yml#L75-L90
> >>
> >> the "- name: Ensuring ovsdpdk bridges are properly setup named" task
> >> does not use --no-wait when creating bridges and adding interfaces
> so
> >> it will fail if the vswitchd is not running. This will result in
> >> ansible stopping to run any futher task on that node and reporting
> >> the error to the user. If for some reason the ensure bridge task
> >> passed the next task that check an ip is assigned to the ovs bride
> >> would fail.
> >
> > Okay - thanks for the pointers, I'll check it out.
> >
> >>>
> >>> It does seem strange that for a possible configuration error we
> >>> abort()
> >> [Mooney, Sean K] why I would expect this to be standard behavior for
> any deamon.
> >> e.g. the damon would validate it config is correct and exit if
> invalid.
> >> If we don't abort the vswitch is in an undefined state. Is is still
> >> using hugepages For example if the eal init fails after they are
> >> allocated.
> >
> > I see.  I think as of 18.11 (which won't come for 6 months), it will
> > always 'fail' in a known state.  But I'll confirm.
> >
> > One of the reasons I want this field is because there will be ways of
> > 'uninitializing'.  I think it's nice to have the ability for the user
> > to dynamically enable *and* disable dpdk.  Also, just from a
> 'selfish'
> > view, I recently was fixing a bug where dpdk initialization would
> fail
> > early with a particular hardware, and it wasn't nice to watch the
> > respawns (racy gdb attach, and coredumps all over the drive).
> >
> >>> running the vswitchd (and with --monitor set, it will continue to
> >>> abort() over and over - so I guess you're also not using the
> monitor
> >>> thread?).  In the case that an abort does happen, does the Kolla
> >>> script distinguish between issues where dpdk setup failed vs. some
> >>> other software issue?
> >>>
>  Can I request that if you make this change you add something along
> >>> the
>  lines of dpdk-init-is-fatal=true/false so that we can explicitly
>  say
> >>> which behavior we want.
>  I would not be surprised if people have built monitoring around
> "is
>  the ovs-vswitchd running"
> >>>
> >>> I think they have, but I don't know that they use it to infer such
> >>> low- level details (meaning a crash implies that dpdk configuration
> >>> is wrong).
> >> [Mooney, Sean K] they don't use is to infer that dpdk configuring is
> >> wronge But rather that some configuration was wrong. Dpdk-init is
> >> currently considered Fatal if it fails so it was treated the same as
> >> any other error that would have caused the vsiwtchd process to exit.
> >> I belive in the opnfv community they used the liveleyness of the
> >> vswitchd 

Re: [ovs-dev] [RFC 0/2] dpdk: minor refactor of the initialization step

[Kevin Traynor]

On 04/11/2018 02:21 PM, Aaron Conole wrote:
> "Mooney, Sean K"  writes:
> 
>>> -Original Message-
>>> From: Aaron Conole [mailto:acon...@redhat.com]
>>> Sent: Monday, April 9, 2018 4:32 PM
>>> To: Mooney, Sean K 
>>> Cc: d...@openvswitch.org; Stokes, Ian ; Kevin
>>> Traynor ; Ilya Maximets ;
>>> Loftus, Ciara ; Terry Wilson
>>> ; Assaf Muller 
>>> Subject: Re: [RFC 0/2] dpdk: minor refactor of the initialization step
>>>
>>> "Mooney, Sean K"  writes:
>>>
 So just from a deployment tools point of view I would like to point
 out that This change could break existing workflow that deploy ovs in
>>> a docker container.
 Kolla ansible assumes that if the docker ovs_vswitchd container is
 still running that the is infact running in dpdk mode when we set
 dpdk-init=true.
>>>
>>> Is there a way to test this out and see the behavior?
>> [Mooney, Sean K] well you could use kolla to deploy ovs-dpdk :)
>> Am when I wrote the code I relied on the existing behavior.
>> when kolla ansible is deploying openstack we first deploy the ovsdb.
>> https://github.com/openstack/kolla-ansible/blob/4c39ea7eccd946775722646eec19f9ea5cbe6eb5/ansible/roles/ovs-dpdk/handlers/main.yml#L2-L37
>> Then we start the ovs-vswitchd container
>> https://github.com/openstack/kolla-ansible/blob/4c39ea7eccd946775722646eec19f9ea5cbe6eb5/ansible/roles/ovs-dpdk/handlers/main.yml#L55-L73
>> finally we configure the bridges and physical interfaces.
>> https://github.com/openstack/kolla-ansible/blob/4c39ea7eccd946775722646eec19f9ea5cbe6eb5/ansible/roles/ovs-dpdk/handlers/main.yml#L75-L90
>>
>> the "- name: Ensuring ovsdpdk bridges are properly setup named" task
>> does not use --no-wait when creating bridges and adding interfaces so
>> it
>> will fail if the vswitchd is not running. This will result in ansible
>> stopping to run any futher task on that node and reporting the error
>> to the user. If for some reason the ensure bridge task passed the next
>> task that check an ip is assigned to the ovs bride would fail.
> 
> Okay - thanks for the pointers, I'll check it out.
> 
>>>
>>> It does seem strange that for a possible configuration error we abort()
>> [Mooney, Sean K] why I would expect this to be standard behavior for any 
>> deamon.
>> e.g. the damon would validate it config is correct and exit if invalid.
>> If we don't abort the vswitch is in an undefined state. Is is still
>> using hugepages
>> For example if the eal init fails after they are allocated.
> 
> I see.  I think as of 18.11 (which won't come for 6 months), it will
> always 'fail' in a known state.  But I'll confirm.
> 
> One of the reasons I want this field is because there will be ways of
> 'uninitializing'.  I think it's nice to have the ability for the user to
> dynamically enable *and* disable dpdk.  Also, just from a 'selfish'
> view, I recently was fixing a bug where dpdk initialization would fail
> early with a particular hardware, and it wasn't nice to watch the
> respawns (racy gdb attach, and coredumps all over the drive).
> 
>>> running the vswitchd (and with --monitor set, it will continue to
>>> abort() over and over - so I guess you're also not using the monitor
>>> thread?).  In the case that an abort does happen, does the Kolla script
>>> distinguish between issues where dpdk setup failed vs. some other
>>> software issue?
>>>
 Can I request that if you make this change you add something along
>>> the
 lines of dpdk-init-is-fatal=true/false so that we can explicitly say
>>> which behavior we want.
 I would not be surprised if people have built monitoring around "is
 the ovs-vswitchd running"
>>>
>>> I think they have, but I don't know that they use it to infer such low-
>>> level details (meaning a crash implies that dpdk configuration is
>>> wrong).
>> [Mooney, Sean K] they don't use is to infer that dpdk configuring is wronge
>> But rather that some configuration was wrong. Dpdk-init is currently 
>> considered
>> Fatal if it fails so it was treated the same as any other error that would 
>> have
>> caused the vsiwtchd process to exit. I belive in the opnfv community they 
>> used
>> the liveleyness of the vswitchd process and in the future dpdk keepalive
>> functionality to set the datapalne status filed in neutron for the host.
>> this allows openstack to be aware of dataplane outages.
> 
> One thing I'll think about more is the dpdk-init.  Maybe, since it is
> stored as a string in the database, we can add a few other values there.
> 
> For instance,
>   dpdk-init=try
> 
> It's like 'true' - only it will continue if there's a failure.  Maybe
> that works?  Just spit-balling.  Thanks for providing insight into the
> way these behaviors are used.
> 

It seems like a good idea to me. Preserves the existing behavior and

Re: [ovs-dev] [PATCH v8 3/6] netdev-dpdk: implement flow offload with rte flow

[Finn Christensen]

>-Original Message-
>From: Stokes, Ian 
>Sent: 10. april 2018 21:59
>To: Shahaf Shuler ; Finn Christensen
>
>Cc: simon.hor...@netronome.com; ovs-dev@openvswitch.org; Chandran,
>Sugesh ; db...@vmware.com; Yuanhan Liu
>
>Subject: RE: [PATCH v8 3/6] netdev-dpdk: implement flow offload with rte
>flow
>
>> The basic yet the major part of this patch is to translate the "match"
>> to rte flow patterns. And then, we create a rte flow with MARK + RSS
>> actions. Afterwards, all packets match the flow will have the mark id
>> in the mbuf.
>>
>> The reason RSS is needed is, for most NICs, a MARK only action is not
>> allowed. It has to be used together with some other actions, such as
>> QUEUE, RSS, etc. However, QUEUE action can specify one queue only,
>> which may break the rss. Likely, RSS action is currently the best we could
>now.
>> Thus, RSS action is choosen.
>>
>> For any unsupported flows, such as MPLS, -1 is returned, meaning the
>> flow offload is failed and then skipped.
>>
>> Co-authored-by: Yuanhan Liu 
>> Signed-off-by: Finn Christensen 
>> Signed-off-by: Yuanhan Liu 
>> Signed-off-by: Shahaf Shuler 
>> ---
>>  lib/netdev-dpdk.c | 563
>> -
>>  1 file changed, 562 insertions(+), 1 deletion(-)
>>
>> diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c index
>> af9843a..df4d480
>> 100644
>> --- a/lib/netdev-dpdk.c
>> +++ b/lib/netdev-dpdk.c
>> @@ -38,7 +38,9 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>
>> +#include "cmap.h"
>>  #include "dirs.h"
>>  #include "dp-packet.h"
>>  #include "dpdk.h"
>> @@ -51,6 +53,7 @@
>>  #include "openvswitch/list.h"
>>  #include "openvswitch/ofp-print.h"
>>  #include "openvswitch/vlog.h"
>> +#include "openvswitch/match.h"
>>  #include "ovs-numa.h"
>>  #include "ovs-thread.h"
>>  #include "ovs-rcu.h"
>> @@ -60,6 +63,7 @@
>>  #include "sset.h"
>>  #include "unaligned.h"
>>  #include "timeval.h"
>> +#include "uuid.h"
>>  #include "unixctl.h"
>>
>>  enum {VIRTIO_RXQ, VIRTIO_TXQ, VIRTIO_QNUM}; @@ -170,6 +174,17 @@
>> static const struct rte_eth_conf port_conf = {  };
>>
>>  /*
>> + * A mapping from ufid to dpdk rte_flow.
>> + */
>> +static struct cmap ufid_to_rte_flow = CMAP_INITIALIZER;
>> +
>> +struct ufid_to_rte_flow_data {
>> +struct cmap_node node;
>> +ovs_u128 ufid;
>> +struct rte_flow *rte_flow;
>> +};
>> +
>> +/*
>>   * These callbacks allow virtio-net devices to be added to vhost
>> ports when
>>   * configuration has been fully completed.
>>   */
>> @@ -3709,6 +3724,552 @@ unlock:
>>  return err;
>>  }
>>
>> +
>> +/* Find rte_flow with @ufid */
>> +static struct rte_flow *
>> +ufid_to_rte_flow_find(const ovs_u128 *ufid) {
>> +size_t hash = hash_bytes(ufid, sizeof(*ufid), 0);
>> +struct ufid_to_rte_flow_data *data;
>> +
>> +CMAP_FOR_EACH_WITH_HASH (data, node, hash, _to_rte_flow) {
>> +if (ovs_u128_equals(*ufid, data->ufid)) {
>> +return data->rte_flow;
>> +}
>> +}
>> +
>> +return NULL;
>> +}
>> +
>> +static inline void
>> +ufid_to_rte_flow_associate(const ovs_u128 *ufid,
>> +   struct rte_flow *rte_flow) {
>> +size_t hash = hash_bytes(ufid, sizeof(*ufid), 0);
>> +struct ufid_to_rte_flow_data *data = xzalloc(sizeof(*data));
>> +
>> +/*
>> + * We should not simply overwrite an existing rte flow.
>> + * We should have deleted it first before re-adding it.
>> + * Thus, if following assert triggers, something is wrong:
>> + * the rte_flow is not destroyed.
>> + */
>> +ovs_assert(ufid_to_rte_flow_find(ufid) == NULL);
>> +
>> +data->ufid = *ufid;
>> +data->rte_flow = rte_flow;
>> +
>> +cmap_insert(_to_rte_flow,
>> +CONST_CAST(struct cmap_node *, >node), hash); }
>> +
>> +static inline void
>> +ufid_to_rte_flow_disassociate(const ovs_u128 *ufid) {
>> +size_t hash = hash_bytes(ufid, sizeof(*ufid), 0);
>> +struct ufid_to_rte_flow_data *data;
>> +
>> +CMAP_FOR_EACH_WITH_HASH (data, node, hash, _to_rte_flow) {
>> +if (ovs_u128_equals(*ufid, data->ufid)) {
>> +cmap_remove(_to_rte_flow,
>> +CONST_CAST(struct cmap_node *, >node),
>> hash);
>> +free(data);
>> +return;
>> +}
>> +}
>> +
>> +VLOG_WARN("ufid "UUID_FMT" is not associated with an rte flow\n",
>> +  UUID_ARGS((struct uuid *)ufid)); }
>> +
>> +/*
>> + * To avoid individual xrealloc calls for each new element, a
>> 'curent_max'
>> + * is used to keep track of current allocated number of elements.
>> +Starts
>> + * by 8 and doubles on each xrealloc call  */ struct flow_patterns {
>> +struct rte_flow_item *items;
>> +int cnt;
>> +int current_max;
>> +};
>> +
>> +struct flow_actions {
>> +

Re: [ovs-dev] [PATCH 2/2] dpdk docs: Drop file share in libvirt config.

[Aaron Conole]

Stephen Finucane  writes:

> On Wed, 2018-04-11 at 09:54 -0400, Aaron Conole wrote:
>> Tiago Lam  writes:
>> 
>> > When explaining on how to add vhost-user ports to a guest, using
>> > libvirt, the following piece of configuration is used:
>> > 
>> >   
>> >   
>> >   
>> >   
>> > 
>> > 
>> > This is used to facilitate sharing of a DPDK directory between the host
>> > and the guest. However, for this to work selinux also needs to be
>> > configured (or disabled).  Furthermore, if one is using Ubuntu, libvirtd
>> > would need to be added to complain only in AppArmor. Instead, in [1] it
>> > is advised to use wget to get the DPDK sources over the internet, which
>> > avoids this differentiation. Thus, we drop this piece of configuration
>> > here as well and keep the example configuration as simple as possible.
>> > 
>> > This has been verified on both a Fedora 27 image and a Ubuntu 16.04 LTS
>> > image.
>> > 
>> > [1] 
>> > http://docs.openvswitch.org/en/latest/topics/dpdk/vhost-user/#dpdk-in-the-guest
>> > 
>> > Signed-off-by: Tiago Lam 
>> > ---
>> > 
>> > CC'ed Stephen,
>> > 
>> > I took the liberty of removing your TODO from here, as I read it to be 
>> > related
>> > to the (now removed) SELinux instruction below. If you think it should 
>> > still be
>> > there let me know and I'll gladly send a v2.
>> 
>> I think it should remain until the selinux issues have been addressed.
>> 
>> Is there a list somewhere of the AVC denials?  Maybe it makes sense to
>> allow them.
>
> If I'm reading this correctly, Tiago is saying these exceptions only
> happen because we're sharing an arbitrary directory with the guest to
> avoid downloading the DPDK sources twice.

Okay, I guess I read the change in the section a bit differently.  If
you think it's okay, then I'm fine (I'm always happy to see a
'setenforce 0' disappear).

> Given that there's a valid
> workaround (just fetching sources twice), simply removing that section
> of the XML removes the need to disable SELinux. If so, dropping the
> warning does make sense in my mind.
>
> Stephen
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH] stopwatch: Add latch_poll to stopwatch loop.

[Mark Michelson]

Nothing was clearing the latch, so the loop was busy. This makes it so
the loop only runs on new calls to latch_set() by a separate thread.

Signed-off-by: Mark Michelson 
---
 lib/stopwatch.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lib/stopwatch.c b/lib/stopwatch.c
index bd40434af..20e2eefc0 100644
--- a/lib/stopwatch.c
+++ b/lib/stopwatch.c
@@ -429,6 +429,7 @@ stopwatch_thread(void *ign OVS_UNUSED)
 struct ovs_list command_list;
 struct stopwatch_packet *pkt;
 
+latch_poll(_latch);
 guarded_list_pop_all(_commands, _list);
 ovs_mutex_lock(_lock);
 LIST_FOR_EACH_POP (pkt, list_node, _list) {
-- 
2.14.3

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

Re: [ovs-dev] [PATCH 2/2] dpdk docs: Drop file share in libvirt config.

[Stephen Finucane]

On Wed, 2018-04-11 at 09:54 -0400, Aaron Conole wrote:
> Tiago Lam  writes:
> 
> > When explaining on how to add vhost-user ports to a guest, using
> > libvirt, the following piece of configuration is used:
> > 
> >   
> >   
> >   
> >   
> > 
> > 
> > This is used to facilitate sharing of a DPDK directory between the host
> > and the guest. However, for this to work selinux also needs to be
> > configured (or disabled).  Furthermore, if one is using Ubuntu, libvirtd
> > would need to be added to complain only in AppArmor. Instead, in [1] it
> > is advised to use wget to get the DPDK sources over the internet, which
> > avoids this differentiation. Thus, we drop this piece of configuration
> > here as well and keep the example configuration as simple as possible.
> > 
> > This has been verified on both a Fedora 27 image and a Ubuntu 16.04 LTS
> > image.
> > 
> > [1] 
> > http://docs.openvswitch.org/en/latest/topics/dpdk/vhost-user/#dpdk-in-the-guest
> > 
> > Signed-off-by: Tiago Lam 
> > ---
> > 
> > CC'ed Stephen,
> > 
> > I took the liberty of removing your TODO from here, as I read it to be 
> > related
> > to the (now removed) SELinux instruction below. If you think it should 
> > still be
> > there let me know and I'll gladly send a v2.
> 
> I think it should remain until the selinux issues have been addressed.
> 
> Is there a list somewhere of the AVC denials?  Maybe it makes sense to
> allow them.

If I'm reading this correctly, Tiago is saying these exceptions only
happen because we're sharing an arbitrary directory with the guest to
avoid downloading the DPDK sources twice. Given that there's a valid
workaround (just fetching sources twice), simply removing that section
of the XML removes the need to disable SELinux. If so, dropping the
warning does make sense in my mind.

Stephen
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 2/2] dpdk docs: Drop file share in libvirt config.

[Aaron Conole]

Tiago Lam  writes:

> When explaining on how to add vhost-user ports to a guest, using
> libvirt, the following piece of configuration is used:
> 
>   
>   
>   
>   
> 
>
> This is used to facilitate sharing of a DPDK directory between the host
> and the guest. However, for this to work selinux also needs to be
> configured (or disabled).  Furthermore, if one is using Ubuntu, libvirtd
> would need to be added to complain only in AppArmor. Instead, in [1] it
> is advised to use wget to get the DPDK sources over the internet, which
> avoids this differentiation. Thus, we drop this piece of configuration
> here as well and keep the example configuration as simple as possible.
>
> This has been verified on both a Fedora 27 image and a Ubuntu 16.04 LTS
> image.
>
> [1] 
> http://docs.openvswitch.org/en/latest/topics/dpdk/vhost-user/#dpdk-in-the-guest
>
> Signed-off-by: Tiago Lam 
> ---
>
> CC'ed Stephen,
>
> I took the liberty of removing your TODO from here, as I read it to be related
> to the (now removed) SELinux instruction below. If you think it should still 
> be
> there let me know and I'll gladly send a v2.

I think it should remain until the selinux issues have been addressed.

Is there a list somewhere of the AVC denials?  Maybe it makes sense to
allow them.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 1/2] dpdk docs: Drop qemu-kvm for qemu-system-x86_64.

[Aaron Conole]

Tiago Lam  writes:

> When explaining on how to add vhost-user ports to a guest, using
> libvirt, point to the qemu-system-x86_64 binary by default, instead of
> using qemu-kvm. The latter has been made obsolete and dropped from a
> number of distributions (although it is still available on Fedora).
>
> This has been verified on both a Fedora 27 image and a Ubuntu 16.04 LTS
> image.
>
> Signed-off-by: Tiago Lam 
> ---
>  Documentation/topics/dpdk/vhost-user.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/topics/dpdk/vhost-user.rst 
> b/Documentation/topics/dpdk/vhost-user.rst
> index ca8a328..74bab78 100644
> --- a/Documentation/topics/dpdk/vhost-user.rst
> +++ b/Documentation/topics/dpdk/vhost-user.rst
> @@ -401,7 +401,7 @@ Sample XML
>restart
>destroy
>
> -/usr/bin/qemu-kvm

Looks like this isn't even a proper path on some systems.  For example,
RHEL7 it's:

  /usr/libexec/qemu-kvm

So it's doubly wrong.

> +/usr/bin/qemu-system-x86_64
>  
>
>

On the other hand, on my RHEL7.4 system, I don't have
qemu-system-x86_64, but I do have qemu-kvm.

I do like cookbook examples, but it seems that sometimes the care and
feeding of these sections gets cumbersome.  Maybe there's a way of
including just the xml portions we need for a vhost-enabled libvirt xml
configuration?

Just a thought.

Anyway:

  Acked-by: Aaron Conole 

Thanks, Tiago!
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [RFC 0/2] dpdk: minor refactor of the initialization step

[Aaron Conole]

"Mooney, Sean K"  writes:

>> -Original Message-
>> From: Aaron Conole [mailto:acon...@redhat.com]
>> Sent: Monday, April 9, 2018 4:32 PM
>> To: Mooney, Sean K 
>> Cc: d...@openvswitch.org; Stokes, Ian ; Kevin
>> Traynor ; Ilya Maximets ;
>> Loftus, Ciara ; Terry Wilson
>> ; Assaf Muller 
>> Subject: Re: [RFC 0/2] dpdk: minor refactor of the initialization step
>> 
>> "Mooney, Sean K"  writes:
>> 
>> > So just from a deployment tools point of view I would like to point
>> > out that This change could break existing workflow that deploy ovs in
>> a docker container.
>> > Kolla ansible assumes that if the docker ovs_vswitchd container is
>> > still running that the is infact running in dpdk mode when we set
>> > dpdk-init=true.
>> 
>> Is there a way to test this out and see the behavior?
> [Mooney, Sean K] well you could use kolla to deploy ovs-dpdk :)
> Am when I wrote the code I relied on the existing behavior.
> when kolla ansible is deploying openstack we first deploy the ovsdb.
> https://github.com/openstack/kolla-ansible/blob/4c39ea7eccd946775722646eec19f9ea5cbe6eb5/ansible/roles/ovs-dpdk/handlers/main.yml#L2-L37
> Then we start the ovs-vswitchd container
> https://github.com/openstack/kolla-ansible/blob/4c39ea7eccd946775722646eec19f9ea5cbe6eb5/ansible/roles/ovs-dpdk/handlers/main.yml#L55-L73
> finally we configure the bridges and physical interfaces.
> https://github.com/openstack/kolla-ansible/blob/4c39ea7eccd946775722646eec19f9ea5cbe6eb5/ansible/roles/ovs-dpdk/handlers/main.yml#L75-L90
>
> the "- name: Ensuring ovsdpdk bridges are properly setup named" task
> does not use --no-wait when creating bridges and adding interfaces so
> it
> will fail if the vswitchd is not running. This will result in ansible
> stopping to run any futher task on that node and reporting the error
> to the user. If for some reason the ensure bridge task passed the next
> task that check an ip is assigned to the ovs bride would fail.

Okay - thanks for the pointers, I'll check it out.

>> 
>> It does seem strange that for a possible configuration error we abort()
> [Mooney, Sean K] why I would expect this to be standard behavior for any 
> deamon.
> e.g. the damon would validate it config is correct and exit if invalid.
> If we don't abort the vswitch is in an undefined state. Is is still
> using hugepages
> For example if the eal init fails after they are allocated.

I see.  I think as of 18.11 (which won't come for 6 months), it will
always 'fail' in a known state.  But I'll confirm.

One of the reasons I want this field is because there will be ways of
'uninitializing'.  I think it's nice to have the ability for the user to
dynamically enable *and* disable dpdk.  Also, just from a 'selfish'
view, I recently was fixing a bug where dpdk initialization would fail
early with a particular hardware, and it wasn't nice to watch the
respawns (racy gdb attach, and coredumps all over the drive).

>> running the vswitchd (and with --monitor set, it will continue to
>> abort() over and over - so I guess you're also not using the monitor
>> thread?).  In the case that an abort does happen, does the Kolla script
>> distinguish between issues where dpdk setup failed vs. some other
>> software issue?
>> 
>> > Can I request that if you make this change you add something along
>> the
>> > lines of dpdk-init-is-fatal=true/false so that we can explicitly say
>> which behavior we want.
>> > I would not be surprised if people have built monitoring around "is
>> > the ovs-vswitchd running"
>> 
>> I think they have, but I don't know that they use it to infer such low-
>> level details (meaning a crash implies that dpdk configuration is
>> wrong).
> [Mooney, Sean K] they don't use is to infer that dpdk configuring is wronge
> But rather that some configuration was wrong. Dpdk-init is currently 
> considered
> Fatal if it fails so it was treated the same as any other error that would 
> have
> caused the vsiwtchd process to exit. I belive in the opnfv community they used
> the liveleyness of the vswitchd process and in the future dpdk keepalive
> functionality to set the datapalne status filed in neutron for the host.
> this allows openstack to be aware of dataplane outages.

One thing I'll think about more is the dpdk-init.  Maybe, since it is
stored as a string in the database, we can add a few other values there.

For instance,
  dpdk-init=try

It's like 'true' - only it will continue if there's a failure.  Maybe
that works?  Just spit-balling.  Thanks for providing insight into the
way these behaviors are used.

>> 
>> > To infer at least at a highlevel that "everything is fine" where as
>> > the log message/db field proposed Here will invalidate that.
>> 
>> I've added Assaf Mueller from our Open Stack team as well - maybe he
>> has 

Re: [ovs-dev] [PATCH v8 5/6] dpif-netdev: do hw flow offload in a thread

[Shahaf Shuler]

Tuesday, April 10, 2018 10:58 PM, Stokes, Ian:
> Subject: RE: [PATCH v8 5/6] dpif-netdev: do hw flow offload in a thread
> 
> > Currently, the major trigger for hw flow offload is at upcall
> > handling, which is actually in the datapath. Moreover, the hw offload
> > installation and modification is not that lightweight. Meaning, if
> > there are so many flows being added or modified frequently, it could
> > stall the datapath, which could result to packet loss.
> >
> > To diminish that, all those flow operations will be recorded and
> > appended to a list. A thread is then introduced to process this list
> > (to do the real flow offloading put/del operations). This could leave
> > the datapath as lightweight as possible.
> 
> Just a general query and not related to this patch specifically, but have you
> given any thought to statistics for the HWOL usecase? Should they be tracked
> in any way for OVS or if tracked by the NIC can they be accessed by OVS?

For Hardware offload, for supported devices, we can aid the help of the NIC for 
statistics of the flow rules. 
The APIs are already in DPDK. One can associate flow rule with a count action 
to have full count by the NIC for packet match this flow.
In case HW not supports, then counting can be done by the OVS. 

For Mellanox, flow counters by HW are supported. Not sure about the rest of the 
vendors. 

Having said that, I think the gain from HW offload for flow mark statistics is 
low, because the packet is processed by OVS regardless. 
For more advance HWOL like drop action / redirect action it is mandatory. 

> 
> More comments inline below.
> >
> > Signed-off-by: Yuanhan Liu 
> > Signed-off-by: Shahaf Shuler 
> > ---
> >  lib/dpif-netdev.c | 348
> > -
> >  1 file changed, 258 insertions(+), 90 deletions(-)
> >
> > diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c index
> > 7489a2f..8300286
> > 100644
> > --- a/lib/dpif-netdev.c
> > +++ b/lib/dpif-netdev.c
> > @@ -345,6 +345,12 @@ enum rxq_cycles_counter_type {
> >  RXQ_N_CYCLES
> >  };
> >
> > +enum {
> > +DP_NETDEV_FLOW_OFFLOAD_OP_ADD,
> > +DP_NETDEV_FLOW_OFFLOAD_OP_MOD,
> > +DP_NETDEV_FLOW_OFFLOAD_OP_DEL,
> > +};
> > +
> >  #define XPS_TIMEOUT 50LL/* In microseconds. */
> >
> >  /* Contained by struct dp_netdev_port's 'rxqs' member.  */ @@ -721,6
> > +727,8 @@ static inline bool emc_entry_alive(struct emc_entry *ce);
> > static void emc_clear_entry(struct emc_entry *ce);
> >
> >  static void dp_netdev_request_reconfigure(struct dp_netdev *dp);
> > +static void queue_netdev_flow_del(struct dp_netdev_pmd_thread
> *pmd,
> > +  struct dp_netdev_flow *flow);
> >
> >  static void
> >  emc_cache_init(struct emc_cache *flow_cache) @@ -1854,13 +1862,11
> @@
> > struct flow_mark {
> >  struct cmap megaflow_to_mark;
> >  struct cmap mark_to_flow;
> >  struct id_pool *pool;
> > -struct ovs_mutex mutex;
> >  };
> >
> >  static struct flow_mark flow_mark = {
> >  .megaflow_to_mark = CMAP_INITIALIZER,
> >  .mark_to_flow = CMAP_INITIALIZER,
> > -.mutex = OVS_MUTEX_INITIALIZER,
> >  };
> >
> >  static uint32_t
> > @@ -2010,7 +2016,7 @@ flow_mark_flush(struct dp_netdev_pmd_thread
> > *pmd)
> >
> >  CMAP_FOR_EACH (flow, mark_node, _mark.mark_to_flow) {
> >  if (flow->pmd_id == pmd->core_id) {
> > -mark_to_flow_disassociate(pmd, flow);
> > +queue_netdev_flow_del(pmd, flow);
> >  }
> >  }
> >  }
> > @@ -2032,6 +2038,251 @@ mark_to_flow_find(const struct
> > dp_netdev_pmd_thread *pmd,
> >  return NULL;
> >  }
> >
> > +struct dp_flow_offload_item {
> > +struct dp_netdev_pmd_thread *pmd;
> > +struct dp_netdev_flow *flow;
> > +int op;
> > +struct match match;
> > +struct nlattr *actions;
> > +size_t actions_len;
> > +
> > +struct ovs_list node;
> > +};
> > +
> > +struct dp_flow_offload {
> > +struct ovs_mutex mutex;
> > +struct ovs_list list;
> > +pthread_cond_t cond;
> > +};
> > +
> > +static struct dp_flow_offload dp_flow_offload = {
> > +.mutex = OVS_MUTEX_INITIALIZER,
> > +.list  = OVS_LIST_INITIALIZER(_flow_offload.list),
> > +};
> > +
> > +static struct ovsthread_once offload_thread_once
> > += OVSTHREAD_ONCE_INITIALIZER;
> 
> The structs above are declared mid file after the pre-existing
> mark_to_flow_find function.
> 
> It would look cleaner if declared toward the beginning with the enums etc, so
> as to keep functions and structs separate.
> > +
> > +static struct dp_flow_offload_item *
> > +dp_netdev_alloc_flow_offload(struct dp_netdev_pmd_thread *pmd,
> > + struct dp_netdev_flow *flow,
> > + int op)
> > +{
> > +struct dp_flow_offload_item *offload;
> > +
> > +offload = xzalloc(sizeof(*offload));
> > +offload->pmd = pmd;
> > +offload->flow = flow;
> > +

Re: [ovs-dev] [PATCH] netdev-dpdk: fix MAC address in port addr example

[Marcelo Ricardo Leitner]

On Wed, Apr 11, 2018 at 12:15:28PM +, Stokes, Ian wrote:
> > Seems the doc just wasn't updated when they settled for a way of
> > addressing this issue.
>
> Agreed, I've validated with a Mellanox Connect X3 pro card, 6 bytes
> was expected.
>
> Thanks for this Marcelo, I see Timothy Redaelli (from Red Hat also)
> has submitted a similar patch.
>
> https://mail.openvswitch.org/pipermail/ovs-dev/2018-April/345885.html

Oh, wasn't aware of that. Sorry Timothy, and thanks.

>
> There was a request to fix the commit message for that patch however.
>
> @Timothy: As this patch has the correct commit message I can merge
> this to dpdk_merge if there are no objections rather than you
> spinning a v2 for yours?
>
> Thanks
> Ian
>
> >
> > Thanks,
> > Marcelo
> >
> > >
> > > Regards,
> > > Billy.
> > >
> > > > -Original Message-
> > > > From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-
> > > > boun...@openvswitch.org] On Behalf Of Marcelo Ricardo Leitner
> > > > Sent: Monday, April 9, 2018 6:21 PM
> > > > To: d...@openvswitch.org
> > > > Cc: marcelo.leit...@gmail.com; slav...@mellanox.com
> > > > Subject: [ovs-dev] [PATCH] netdev-dpdk: fix MAC address in port addr
> > > > example
> > > >
> > > > The MAC address is always 6-bytes long, never 7. The extra :01 and
> > > > :02 doesn't belong in there as it doesn't mean selecting one port or
> > another.
> > > >
> > > > Instead, use an incrementing MAC address, which is what usually
> > > > happens on such cards.
> > > >
> > > > See-also: http://www.dpdk.org/ml/archives/dev/2018-April/094976.html
> > > > Fixes: 5e7588186839 ("netdev-dpdk: fix port addition for ports
> > > > sharing same PCI
> > > > id")
> > > > Signed-off-by: Marcelo Ricardo Leitner 
> > > > ---
> > > >  Documentation/howto/dpdk.rst | 4 ++--
> > > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/Documentation/howto/dpdk.rst
> > > > b/Documentation/howto/dpdk.rst index
> > > > 79b626c76d0dd45381bd75ab867b7815ca941208..69e692f40d500cf65d59d1979
> > > > e07afa6f99cf903 100644
> > > > --- a/Documentation/howto/dpdk.rst
> > > > +++ b/Documentation/howto/dpdk.rst
> > > > @@ -53,9 +53,9 @@ 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:01"
> > > > +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:55:02"
> > > > +options:dpdk-devargs="class=eth,mac=00:11:22:33:44:56"
> > > >
> > > >  Note: such syntax won't support hotplug. The hotplug is supposed to
> > > > work with future DPDK release, v18.05.
> > > > --
> > > > 2.14.3
> > > >
> > > > ___
> > > > 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
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v8 2/6] dpif-netdev: retrieve flow directly from the flow mark

[Shahaf Shuler]

Tuesday, April 10, 2018 10:58 PM, Stokes, Ian:
> Subject: RE: [PATCH v8 2/6] dpif-netdev: retrieve flow directly from the flow
> mark
> 
> > Subject: [PATCH v8 2/6] dpif-netdev: retrieve flow directly from the
> > flow mark
> >
> > From: Yuanhan Liu 
> >
> > So that we could skip some very costly CPU operations, including but
> > not limiting to miniflow_extract, emc lookup, dpcls lookup, etc. Thus,
> > performance could be greatly improved.
> >
> > A PHY-PHY forwarding with 1000 mega flows (udp,tp_src=1000-1999) and
> > 1 million streams (tp_src=1000-1999, tp_dst=2000-2999) show more that
> > 260% performance boost.
> >
> > Note that though the heavy miniflow_extract is skipped, we still have
> > to do per packet checking, due to we have to check the tcp_flags.
> >
> > Co-authored-by: Finn Christensen 
> > Signed-off-by: Yuanhan Liu 
> > Signed-off-by: Finn Christensen 
> > Signed-off-by: Shahaf Shuler 
> > ---
> >  lib/dp-packet.h   |  13 +
> >  lib/dpif-netdev.c |  44 --
> >  lib/flow.c| 155 +++-
> -
> >  lib/flow.h|   1 +
> >  4 files changed, 175 insertions(+), 38 deletions(-)
> >
> > diff --git a/lib/dp-packet.h b/lib/dp-packet.h index 21c8ca5..dd3f17b
> > 100644
> > --- a/lib/dp-packet.h
> > +++ b/lib/dp-packet.h
> > @@ -691,6 +691,19 @@ reset_dp_packet_checksum_ol_flags(struct
> > dp_packet
> > *p)  #define reset_dp_packet_checksum_ol_flags(arg)
> >  #endif
> >
> > +static inline bool
> > +dp_packet_has_flow_mark(struct dp_packet *p OVS_UNUSED,
> > +uint32_t *mark OVS_UNUSED) { #ifdef DPDK_NETDEV
> > +if (p->mbuf.ol_flags & PKT_RX_FDIR_ID) {
> > +*mark = p->mbuf.hash.fdir.hi;
> > +return true;
> > +}
> > +#endif
> > +return false;
> > +}
> > +
> >  enum { NETDEV_MAX_BURST = 32 }; /* Maximum number packets in a
> batch.
> > */
> >
> >  struct dp_packet_batch {
> > diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c index
> > 2fdb6ef..7489a2f
> > 100644
> > --- a/lib/dpif-netdev.c
> > +++ b/lib/dpif-netdev.c
> > @@ -2015,6 +2015,23 @@ flow_mark_flush(struct
> dp_netdev_pmd_thread *pmd)
> >  }
> >  }
> >
> > +static struct dp_netdev_flow *
> > +mark_to_flow_find(const struct dp_netdev_pmd_thread *pmd,
> > +  const uint32_t mark) {
> > +struct dp_netdev_flow *flow;
> > +
> > +CMAP_FOR_EACH_WITH_HASH (flow, mark_node, hash_int(mark, 0),
> > + _mark.mark_to_flow) {
> > +if (flow->mark == mark && flow->pmd_id == pmd->core_id &&
> > +flow->dead == false) {
> > +return flow;
> > +}
> > +}
> > +
> > +return NULL;
> > +}
> > +
> >  static void
> >  dp_netdev_pmd_remove_flow(struct dp_netdev_pmd_thread *pmd,
> >struct dp_netdev_flow *flow) @@ -5204,10
> > +5221,10 @@ struct packet_batch_per_flow {  static inline void
> > packet_batch_per_flow_update(struct packet_batch_per_flow *batch,
> >   struct dp_packet *packet,
> > - const struct miniflow *mf)
> > + uint16_t tcp_flags)
> >  {
> >  batch->byte_count += dp_packet_size(packet);
> > -batch->tcp_flags |= miniflow_get_tcp_flags(mf);
> > +batch->tcp_flags |= tcp_flags;
> >  batch->array.packets[batch->array.count++] = packet;  }
> >
> > @@ -5241,7 +5258,7 @@ packet_batch_per_flow_execute(struct
> > packet_batch_per_flow *batch,
> >
> >  static inline void
> >  dp_netdev_queue_batches(struct dp_packet *pkt,
> > -struct dp_netdev_flow *flow, const struct
> > miniflow *mf,
> > +struct dp_netdev_flow *flow, uint16_t
> > + tcp_flags,
> >  struct packet_batch_per_flow *batches,
> >  size_t *n_batches)  { @@ -5252,7 +5269,7 @@
> > dp_netdev_queue_batches(struct dp_packet *pkt,
> >  packet_batch_per_flow_init(batch, flow);
> >  }
> >
> > -packet_batch_per_flow_update(batch, pkt, mf);
> > +packet_batch_per_flow_update(batch, pkt, tcp_flags);
> >  }
> >
> >  /* Try to process all ('cnt') the 'packets' using only the exact
> > match cache @@ -5283,6 +5300,7 @@ emc_processing(struct
> > dp_netdev_pmd_thread *pmd,
> >  const size_t cnt = dp_packet_batch_size(packets_);
> >  uint32_t cur_min;
> >  int i;
> > +uint16_t tcp_flags;
> >
> >  atomic_read_relaxed(>dp->emc_insert_min, _min);
> >  pmd_perf_update_counter(>perf_stats,
> > @@ -5291,6 +5309,7 @@ emc_processing(struct dp_netdev_pmd_thread
> *pmd,
> >
> >  DP_PACKET_BATCH_REFILL_FOR_EACH (i, cnt, packet, packets_) {
> >  struct dp_netdev_flow *flow;
> > +uint32_t mark;
> >
> >  if (OVS_UNLIKELY(dp_packet_size(packet) < ETH_HEADER_LEN)) {
> >  dp_packet_delete(packet); @@ -5298,6 +5317,16 

Re: [ovs-dev] [PATCH] netdev-dpdk: fix MAC address in port addr example

[Stokes, Ian]

> Hi Billy,
> 
> On Wed, Apr 11, 2018 at 09:31:39AM +, O Mahony, Billy wrote:
> > Hi Marcelo,
> >
> > I haven't used the specific cards referred to in the surrounding
> > documentation but I don't think the 'mac' address format is a typo.
> >
> > The notation is specific to some vendor NICs that have several
> > Ethernet devices sharing a single PCI bus:device.function address.
> > In that case the PCI address alone cannot distinguish the Ethernet
> > device to be uses ofr the dpdk port.
> 
> Yes, but
> 
> >
> > "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::"
> 
> I had initially reported this on dev@dpdk and Adrien confirmed that the
> code is not prepared to handle the extra octet. (thread is referenced in
> the See-also in the patch)
> 
> Also, even Mellanox is sending fixes to OpenStack to use standard MAC
> addresses:
> the bug: https://bugs.launchpad.net/os-net-config/+bug/1754256
> part of the patch:
> https://review.openstack.org/#/c/550731/1/os_net_config/utils.py
> which would be enough to specify port A or port B, as they have its own
> MAC address.
> 
> Seems the doc just wasn't updated when they settled for a way of
> addressing this issue.

Agreed, I've validated with a Mellanox Connect X3 pro card, 6 bytes was 
expected.

Thanks for this Marcelo, I see Timothy Redaelli (from Red Hat also) has 
submitted a similar patch.

https://mail.openvswitch.org/pipermail/ovs-dev/2018-April/345885.html

There was a request to fix the commit message for that patch however.

@Timothy: As this patch has the correct commit message I can merge this to 
dpdk_merge if there are no objections rather than you spinning a v2 for yours?

Thanks
Ian

> 
> Thanks,
> Marcelo
> 
> >
> > Regards,
> > Billy.
> >
> > > -Original Message-
> > > From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-
> > > boun...@openvswitch.org] On Behalf Of Marcelo Ricardo Leitner
> > > Sent: Monday, April 9, 2018 6:21 PM
> > > To: d...@openvswitch.org
> > > Cc: marcelo.leit...@gmail.com; slav...@mellanox.com
> > > Subject: [ovs-dev] [PATCH] netdev-dpdk: fix MAC address in port addr
> > > example
> > >
> > > The MAC address is always 6-bytes long, never 7. The extra :01 and
> > > :02 doesn't belong in there as it doesn't mean selecting one port or
> another.
> > >
> > > Instead, use an incrementing MAC address, which is what usually
> > > happens on such cards.
> > >
> > > See-also: http://www.dpdk.org/ml/archives/dev/2018-April/094976.html
> > > Fixes: 5e7588186839 ("netdev-dpdk: fix port addition for ports
> > > sharing same PCI
> > > id")
> > > Signed-off-by: Marcelo Ricardo Leitner 
> > > ---
> > >  Documentation/howto/dpdk.rst | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/Documentation/howto/dpdk.rst
> > > b/Documentation/howto/dpdk.rst index
> > > 79b626c76d0dd45381bd75ab867b7815ca941208..69e692f40d500cf65d59d1979
> > > e07afa6f99cf903 100644
> > > --- a/Documentation/howto/dpdk.rst
> > > +++ b/Documentation/howto/dpdk.rst
> > > @@ -53,9 +53,9 @@ 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:01"
> > > +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:55:02"
> > > +options:dpdk-devargs="class=eth,mac=00:11:22:33:44:56"
> > >
> > >  Note: such syntax won't support hotplug. The hotplug is supposed to
> > > work with future DPDK release, v18.05.
> > > --
> > > 2.14.3
> > >
> > > ___
> > > 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
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] netdev-dpdk: fix MAC address in port addr example

[Marcelo Ricardo Leitner]

Hi Billy,

On Wed, Apr 11, 2018 at 09:31:39AM +, O Mahony, Billy wrote:
> Hi Marcelo,
>
> I haven't used the specific cards referred to in the surrounding
> documentation but I don't think the 'mac' address format is a typo.
>
> The notation is specific to some vendor NICs that have several
> Ethernet devices sharing a single PCI bus:device.function address.
> In that case the PCI address alone cannot distinguish the Ethernet
> device to be uses ofr the dpdk port.

Yes, but

>
> "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::"

I had initially reported this on dev@dpdk and Adrien confirmed that
the code is not prepared to handle the extra octet. (thread is
referenced in the See-also in the patch)

Also, even Mellanox is sending fixes to OpenStack to use standard MAC
addresses:
the bug: https://bugs.launchpad.net/os-net-config/+bug/1754256
part of the patch: 
https://review.openstack.org/#/c/550731/1/os_net_config/utils.py
which would be enough to specify port A or port B, as they have its
own MAC address.

Seems the doc just wasn't updated when they settled for a way of
addressing this issue.

Thanks,
Marcelo

>
> Regards,
> Billy.
>
> > -Original Message-
> > From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-
> > boun...@openvswitch.org] On Behalf Of Marcelo Ricardo Leitner
> > Sent: Monday, April 9, 2018 6:21 PM
> > To: d...@openvswitch.org
> > Cc: marcelo.leit...@gmail.com; slav...@mellanox.com
> > Subject: [ovs-dev] [PATCH] netdev-dpdk: fix MAC address in port addr example
> >
> > The MAC address is always 6-bytes long, never 7. The extra :01 and :02 
> > doesn't
> > belong in there as it doesn't mean selecting one port or another.
> >
> > Instead, use an incrementing MAC address, which is what usually happens on
> > such cards.
> >
> > See-also: http://www.dpdk.org/ml/archives/dev/2018-April/094976.html
> > Fixes: 5e7588186839 ("netdev-dpdk: fix port addition for ports sharing same 
> > PCI
> > id")
> > Signed-off-by: Marcelo Ricardo Leitner 
> > ---
> >  Documentation/howto/dpdk.rst | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/howto/dpdk.rst b/Documentation/howto/dpdk.rst
> > index
> > 79b626c76d0dd45381bd75ab867b7815ca941208..69e692f40d500cf65d59d1979
> > e07afa6f99cf903 100644
> > --- a/Documentation/howto/dpdk.rst
> > +++ b/Documentation/howto/dpdk.rst
> > @@ -53,9 +53,9 @@ 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:01"
> > +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:55:02"
> > +options:dpdk-devargs="class=eth,mac=00:11:22:33:44:56"
> >
> >  Note: such syntax won't support hotplug. The hotplug is supposed to work 
> > with
> > future DPDK release, v18.05.
> > --
> > 2.14.3
> >
> > ___
> > 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

Re: [ovs-dev] [PATCH 1/1] netdev-dpdk: fix RX jumbo for NICs not supporting scatter

[Stokes, Ian]

> > On 10/04/18 21:08, Stokes, Ian wrote:
> >>> Currently to RX jumbo packets fails for NICs not supporting scatter.
> >>> Scatter is not strictly needed for jumbo support on RX. This change
> >>> fixes the issue by only enabling scatter for NICs supporting it.
> >>>
> >>> Reported-by: Louis Peens 
> >>> Signed-off-by: Pablo Cascón 
> >>> Reviewed-by: Simon Horman 
> >>> ---
> >>>   lib/netdev-dpdk.c | 5 -
> >>>   1 file changed, 4 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c index
> >>> ee39cbe..28b20b5
> >>> 100644
> >>> --- a/lib/netdev-dpdk.c
> >>> +++ b/lib/netdev-dpdk.c
> >>> @@ -694,11 +694,14 @@ dpdk_eth_dev_queue_setup(struct netdev_dpdk
> >>> *dev, int n_rxq, int n_txq)
> >>>   int diag = 0;
> >>>   int i;
> >>>   struct rte_eth_conf conf = port_conf;
> >>> +struct rte_eth_dev_info info;
> >>>
> >>>   /* For some NICs (e.g. Niantic), scatter_rx mode needs to be
> >>> explicitly
> >>>* enabled. */
> >>>   if (dev->mtu > ETHER_MTU) {
> >>> -conf.rxmode.enable_scatter = 1;
> >>> +rte_eth_dev_info_get(dev->port_id, );
> >>> +if (info.rx_offload_capa & DEV_RX_OFFLOAD_SCATTER)
> 
> Hi, this was not added until DPDK 17.11, so it's not relevant for OVS
> 2.8 branch.
> 
> Kevin.

Good catch, cheers for the heads up.

Ian
> 
> >>> +conf.rxmode.enable_scatter = 1;
> >> Thanks for this, quick note:
> >>
> >> conf.rxmode.enable_scatter = 1; should be enclosed in braces as per
> >> OVS coding style.
> >
> > Thanks for the feedback, sorry about the lack of braces. Let me know
> > if a v2 is needed
> >>
> >> I'll have some time to test this tomorrow, I take it this should be
> >> backported to OVS2.9 and OVS 2.8 also?
> >
> > Yes please, the change is a welcome one for both 2.8 and 2.9. Also it
> > applies nicely on both. Let me know if a per branch patch is needed.
> >
> > Thanks
> >
> > Pablo
> >
> >>
> >> Ian
> >>
> >>>   }
> >>>
> >>>   conf.rxmode.hw_ip_checksum = (dev->hw_ol_features &
> >>> --
> >>> 2.7.4
> >>>
> >>> ___
> >>> 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

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

Re: [ovs-dev] [PATCH 1/1] netdev-dpdk: fix RX jumbo for NICs not supporting scatter

[Stokes, Ian]

> >> Currently to RX jumbo packets fails for NICs not supporting scatter.
> >> Scatter is not strictly needed for jumbo support on RX. This change
> >> fixes the issue by only enabling scatter for NICs supporting it.
> >>
> >> Reported-by: Louis Peens 
> >> Signed-off-by: Pablo Cascón 
> >> Reviewed-by: Simon Horman 
> >> ---
> >>   lib/netdev-dpdk.c | 5 -
> >>   1 file changed, 4 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c index
> >> ee39cbe..28b20b5
> >> 100644
> >> --- a/lib/netdev-dpdk.c
> >> +++ b/lib/netdev-dpdk.c
> >> @@ -694,11 +694,14 @@ dpdk_eth_dev_queue_setup(struct netdev_dpdk
> >> *dev, int n_rxq, int n_txq)
> >>   int diag = 0;
> >>   int i;
> >>   struct rte_eth_conf conf = port_conf;
> >> +struct rte_eth_dev_info info;
> >>
> >>   /* For some NICs (e.g. Niantic), scatter_rx mode needs to be
> >> explicitly
> >>* enabled. */
> >>   if (dev->mtu > ETHER_MTU) {
> >> -conf.rxmode.enable_scatter = 1;
> >> +rte_eth_dev_info_get(dev->port_id, );
> >> +if (info.rx_offload_capa & DEV_RX_OFFLOAD_SCATTER)
> >> +conf.rxmode.enable_scatter = 1;
> > Thanks for this, quick note:
> >
> > conf.rxmode.enable_scatter = 1; should be enclosed in braces as per OVS
> coding style.
> 
> Thanks for the feedback, sorry about the lack of braces. Let me know if a
> v2 is needed

No need, I can add an incremental on commit.

Thanks
Ian
> >
> > I'll have some time to test this tomorrow, I take it this should be
> backported to OVS2.9 and OVS 2.8 also?
> 
> Yes please, the change is a welcome one for both 2.8 and 2.9. Also it
> applies nicely on both. Let me know if a per branch patch is needed.
> 
> Thanks
> 
> Pablo
> 
> >
> > Ian
> >
> >>   }
> >>
> >>   conf.rxmode.hw_ip_checksum = (dev->hw_ol_features &
> >> --
> >> 2.7.4
> >>
> >> ___
> >> 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

Re: [ovs-dev] [PATCH 1/1] netdev-dpdk: fix RX jumbo for NICs not supporting scatter

[Kevin Traynor]

On 04/11/2018 12:10 PM, Pablo Cascón wrote:
> On 10/04/18 21:08, Stokes, Ian wrote:
>>> Currently to RX jumbo packets fails for NICs not supporting scatter.
>>> Scatter is not strictly needed for jumbo support on RX. This change
>>> fixes
>>> the issue by only enabling scatter for NICs supporting it.
>>>
>>> Reported-by: Louis Peens 
>>> Signed-off-by: Pablo Cascón 
>>> Reviewed-by: Simon Horman 
>>> ---
>>>   lib/netdev-dpdk.c | 5 -
>>>   1 file changed, 4 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c index
>>> ee39cbe..28b20b5
>>> 100644
>>> --- a/lib/netdev-dpdk.c
>>> +++ b/lib/netdev-dpdk.c
>>> @@ -694,11 +694,14 @@ dpdk_eth_dev_queue_setup(struct netdev_dpdk *dev,
>>> int n_rxq, int n_txq)
>>>   int diag = 0;
>>>   int i;
>>>   struct rte_eth_conf conf = port_conf;
>>> +struct rte_eth_dev_info info;
>>>
>>>   /* For some NICs (e.g. Niantic), scatter_rx mode needs to be
>>> explicitly
>>>* enabled. */
>>>   if (dev->mtu > ETHER_MTU) {
>>> -conf.rxmode.enable_scatter = 1;
>>> +rte_eth_dev_info_get(dev->port_id, );
>>> +if (info.rx_offload_capa & DEV_RX_OFFLOAD_SCATTER)

Hi, this was not added until DPDK 17.11, so it's not relevant for OVS
2.8 branch.

Kevin.

>>> +conf.rxmode.enable_scatter = 1;
>> Thanks for this, quick note:
>>
>> conf.rxmode.enable_scatter = 1; should be enclosed in braces as per
>> OVS coding style.
> 
> Thanks for the feedback, sorry about the lack of braces. Let me know if
> a v2 is needed
>>
>> I'll have some time to test this tomorrow, I take it this should be
>> backported to OVS2.9 and OVS 2.8 also?
> 
> Yes please, the change is a welcome one for both 2.8 and 2.9. Also it
> applies nicely on both. Let me know if a per branch patch is needed.
> 
> Thanks
> 
> Pablo
> 
>>
>> Ian
>>
>>>   }
>>>
>>>   conf.rxmode.hw_ip_checksum = (dev->hw_ol_features &
>>> -- 
>>> 2.7.4
>>>
>>> ___
>>> 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

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

Re: [ovs-dev] [PATCH 1/1] netdev-dpdk: fix RX jumbo for NICs not supporting scatter

[Pablo Cascón]

On 10/04/18 21:08, Stokes, Ian wrote:

Currently to RX jumbo packets fails for NICs not supporting scatter.
Scatter is not strictly needed for jumbo support on RX. This change fixes
the issue by only enabling scatter for NICs supporting it.

Reported-by: Louis Peens 
Signed-off-by: Pablo Cascón 
Reviewed-by: Simon Horman 
---
  lib/netdev-dpdk.c | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c index ee39cbe..28b20b5
100644
--- a/lib/netdev-dpdk.c
+++ b/lib/netdev-dpdk.c
@@ -694,11 +694,14 @@ dpdk_eth_dev_queue_setup(struct netdev_dpdk *dev,
int n_rxq, int n_txq)
  int diag = 0;
  int i;
  struct rte_eth_conf conf = port_conf;
+struct rte_eth_dev_info info;

  /* For some NICs (e.g. Niantic), scatter_rx mode needs to be
explicitly
   * enabled. */
  if (dev->mtu > ETHER_MTU) {
-conf.rxmode.enable_scatter = 1;
+rte_eth_dev_info_get(dev->port_id, );
+if (info.rx_offload_capa & DEV_RX_OFFLOAD_SCATTER)
+conf.rxmode.enable_scatter = 1;

Thanks for this, quick note:

conf.rxmode.enable_scatter = 1; should be enclosed in braces as per OVS coding 
style.


Thanks for the feedback, sorry about the lack of braces. Let me know if 
a v2 is needed


I'll have some time to test this tomorrow, I take it this should be backported 
to OVS2.9 and OVS 2.8 also?


Yes please, the change is a welcome one for both 2.8 and 2.9. Also it 
applies nicely on both. Let me know if a per branch patch is needed.


Thanks

Pablo



Ian


  }

  conf.rxmode.hw_ip_checksum = (dev->hw_ol_features &
--
2.7.4

___
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

[ovs-dev] [PATCH 1/2] dpdk docs: Drop qemu-kvm for qemu-system-x86_64.

[Tiago Lam]

When explaining on how to add vhost-user ports to a guest, using
libvirt, point to the qemu-system-x86_64 binary by default, instead of
using qemu-kvm. The latter has been made obsolete and dropped from a
number of distributions (although it is still available on Fedora).

This has been verified on both a Fedora 27 image and a Ubuntu 16.04 LTS
image.

Signed-off-by: Tiago Lam 
---
 Documentation/topics/dpdk/vhost-user.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/topics/dpdk/vhost-user.rst 
b/Documentation/topics/dpdk/vhost-user.rst
index ca8a328..74bab78 100644
--- a/Documentation/topics/dpdk/vhost-user.rst
+++ b/Documentation/topics/dpdk/vhost-user.rst
@@ -401,7 +401,7 @@ Sample XML
   restart
   destroy
   
-/usr/bin/qemu-kvm
+/usr/bin/qemu-system-x86_64
 
   
   
-- 
2.7.4

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

[ovs-dev] [PATCH 2/2] dpdk docs: Drop file share in libvirt config.

[Tiago Lam]

When explaining on how to add vhost-user ports to a guest, using
libvirt, the following piece of configuration is used:

  
  
  
  


This is used to facilitate sharing of a DPDK directory between the host
and the guest. However, for this to work selinux also needs to be
configured (or disabled).  Furthermore, if one is using Ubuntu, libvirtd
would need to be added to complain only in AppArmor. Instead, in [1] it
is advised to use wget to get the DPDK sources over the internet, which
avoids this differentiation. Thus, we drop this piece of configuration
here as well and keep the example configuration as simple as possible.

This has been verified on both a Fedora 27 image and a Ubuntu 16.04 LTS
image.

[1] 
http://docs.openvswitch.org/en/latest/topics/dpdk/vhost-user/#dpdk-in-the-guest

Signed-off-by: Tiago Lam 
---

CC'ed Stephen,

I took the liberty of removing your TODO from here, as I read it to be related
to the (now removed) SELinux instruction below. If you think it should still be
there let me know and I'll gladly send a v2.

 Documentation/topics/dpdk/vhost-user.rst | 17 ++---
 1 file changed, 2 insertions(+), 15 deletions(-)

diff --git a/Documentation/topics/dpdk/vhost-user.rst 
b/Documentation/topics/dpdk/vhost-user.rst
index 74bab78..6bf16f7 100644
--- a/Documentation/topics/dpdk/vhost-user.rst
+++ b/Documentation/topics/dpdk/vhost-user.rst
@@ -187,21 +187,14 @@ where:
 Adding vhost-user ports to the guest (libvirt)
 ~~
 
-.. TODO(stephenfin): This seems like something that wouldn't be acceptable in
-   production. Is this really required?
-
-To begin, you must change the user and group that libvirt runs under, configure
-access control policy and restart libvirtd.
+To begin, you must change the user and group that qemu runs under, and restart
+libvirtd.
 
 - In ``/etc/libvirt/qemu.conf`` add/edit the following lines::
 
   user = "root"
   group = "root"
 
-- Disable SELinux or set to permissive mode::
-
-  $ setenforce 0
-
 - Finally, restart the libvirtd process, For example, on Fedora::
 
   $ systemctl restart libvirtd.service
@@ -407,12 +400,6 @@ Sample XML
   
   
 
-
-  
-  
-  
-  
-
 
   
   
-- 
2.7.4

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

Re: [ovs-dev] [PATCH] tc: Change filter error to debug once

[Simon Horman]

On Wed, Apr 11, 2018 at 10:57:30AM +0300, Roi Dayan wrote:
> Also update the message to be more correct.
> Before this commit if there were tc rules that are not of type
> flower the log was getting filled quickyl with errors about it
> and always appeared to the user when dumping flows from user space.
> This commit moves the error to debug and logs it only once.
> 
> Signed-off-by: Roi Dayan 
> Reviewed-by: Paul Blakey 

Thanks Roi,

applied to master, branch-2.9 and branch-2.8.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v1] Fix AUTHORS.rst

[Daniel Alvarez Sanchez]

Acked-by: Daniel Alvarez 


Just as a note, normally v1 is not used in the subject, that you can avoid
it by using "git send-email -1 --to=d...@openvswitch.org" and it will send
just the latest commit without adding the v1 tag to the email subject.


On Wed, Apr 11, 2018 at 11:30 AM,  wrote:

> From: Lucas Alvares Gomes 
>
> The commit 9afc6f14ee7b2622703d98689acb0044d4a5492e added a new author
> which name was too long that broke the column size. Runinng "make
> docs-checks" was failing because of that.
>
> All this patch does is to enlarge the "Name" column to fit the new
> author's name.
>
> Signed-off-by: Lucas Alvares Gomes 
> ---
>  AUTHORS.rst | 688 ++--
>  1 file changed, 344 insertions(+), 344 deletions(-)
>
> diff --git a/AUTHORS.rst b/AUTHORS.rst
> index c3e34df88..a097370a8 100644
> --- a/AUTHORS.rst
> +++ b/AUTHORS.rst
> @@ -28,351 +28,351 @@ Authors
>  The following people authored or signed off on commits in the Open
>  vSwitch source code or webpage version control repository.
>
> -=== ==
> =
> -NameEmail
> -=== ==
> =
> -Aaron Conoleacon...@redhat.com
> -Aaron Rosen aro...@clemson.edu
> -Alan Pevec  alan.pe...@redhat.com
> -Alexander Duyck alexander.h.du...@redhat.com
> -Alexandru Copot alex.miha...@gmail.com
> -Alexei Starovoitov  a...@plumgrid.com
> -Alexey I. Froloff   ra...@raorn.name
> -Alex Wang   ee07b...@gmail.com
> -Alfredo Finelli a...@computationes.de
> -Alin Balutoiu   abalut...@cloudbasesolutions.com
> -Alin Serdeanaserd...@cloudbasesolutions.com
> -Ambika Aroraambika.ar...@tcs.com
> -Amit Bose   b...@noironetworks.com
> -Amitabha Biswas azbis...@gmail.com
> -Anand Kumar kumaran...@vmware.com
> -Andrew Evansaev...@nicira.com
> -Andrew Beekhof  abeek...@redhat.com
> -Andrew Kampjes  a.kamp...@gmail.com
> -Andrew Lambeth  w...@nicira.com
> -Andy Hill   hil...@gmail.com
> -Andy Southgate  andy.southg...@citrix.com
> -Andy Zhou   az...@ovn.org
> -Ankur Sharmaankursha...@vmware.com
> -Anoob Soman anoob.so...@citrix.com
> -Ansis Attekaaatt...@nicira.com
> -Antonio Fischetti   antonio.fische...@intel.com
> -Anupam Chanda   acha...@nicira.com
> -Ariel Tubaltsev atubalt...@vmware.com
> -Arnoldo Lutzarnoldo.lutz.guev...@hpe.com
> -Arun Sharma arun.sha...@calsoftinc.com
> -Aryan TaheriMonfaredaryan.taherimonfa...@uis.no
> -Ashish Varmaashishvarma@gmail.com
> -Ashwin Swaminathan  ashwi...@arista.com
> -Babu Shanmugam  bscha...@redhat.com
> -Ben Pfaff   b...@ovn.org
> -Ben Warren  b...@skyportsystems.com
> -Benli Yedani...@vmware.com
> -Bert Vermeulen  b...@biot.com
> -Bhanuprakash Bodireddy  bhanuprakash.bodire...@intel.com
> -Billy O'Mahony  billy.o.mah...@intel.com
> -Binbin Xu   xu.binb...@zte.com.cn
> -Brian Krugerbkruger+ovs...@gmail.com
> -Bruce Davie b...@nicira.com
> -Bryan Phillippe b...@toroki.com
> -Carlo Andreotti c.andreo...@m3s.it
> -Casey Barkercrbar...@google.com
> -Chandra Sekhar Vejendla csvej...@us.ibm.com
> -Christoph Jaegerc...@linux.com
> -Chris Wrightchr...@sous-sol.org
> -Chuck Short zul...@ubuntu.com
> -Ciara Loftusciara.lof...@intel.com
> -Clint Byrum cl...@fewbar.com
> -Cong Wang   amw...@redhat.com
> -Conner Herriges conner.herri...@ibm.com
> -Damien Millescamps  damien.millesca...@6wind.com
> -Dan Carpenter   dan.carpen...@oracle.com
> -Dan McGregordan.mcgre...@usask.ca
> -Dan Wendlandt   d...@nicira.com
> -Dan Williamsd...@redhat.com
> -Daniel Alvarez  dalva...@redhat.com
> -Daniel Borkmann dbork...@redhat.com
> -Daniel Hiltgen  dan...@netkine.com
> -Daniel Romandro...@nicira.com
> -Daniele Di Proietto daniele.di.proie...@gmail.com
> -Daniele Venturino 

Re: [ovs-dev] [PATCH] netdev-dpdk: fix MAC address in port addr example

[O Mahony, Billy]

Hi Marcelo,

I haven't used the specific cards referred to in the surrounding documentation 
but I don't think the 'mac' address format is a typo.

The notation is specific to some vendor NICs that have several Ethernet devices 
sharing a single PCI bus:device.function address. In that case the PCI address 
alone cannot distinguish the Ethernet device to be uses ofr the dpdk port.

"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::"

Regards,
Billy. 

> -Original Message-
> From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-
> boun...@openvswitch.org] On Behalf Of Marcelo Ricardo Leitner
> Sent: Monday, April 9, 2018 6:21 PM
> To: d...@openvswitch.org
> Cc: marcelo.leit...@gmail.com; slav...@mellanox.com
> Subject: [ovs-dev] [PATCH] netdev-dpdk: fix MAC address in port addr example
> 
> The MAC address is always 6-bytes long, never 7. The extra :01 and :02 doesn't
> belong in there as it doesn't mean selecting one port or another.
> 
> Instead, use an incrementing MAC address, which is what usually happens on
> such cards.
> 
> See-also: http://www.dpdk.org/ml/archives/dev/2018-April/094976.html
> Fixes: 5e7588186839 ("netdev-dpdk: fix port addition for ports sharing same 
> PCI
> id")
> Signed-off-by: Marcelo Ricardo Leitner 
> ---
>  Documentation/howto/dpdk.rst | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/howto/dpdk.rst b/Documentation/howto/dpdk.rst
> index
> 79b626c76d0dd45381bd75ab867b7815ca941208..69e692f40d500cf65d59d1979
> e07afa6f99cf903 100644
> --- a/Documentation/howto/dpdk.rst
> +++ b/Documentation/howto/dpdk.rst
> @@ -53,9 +53,9 @@ 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:01"
> +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:55:02"
> +options:dpdk-devargs="class=eth,mac=00:11:22:33:44:56"
> 
>  Note: such syntax won't support hotplug. The hotplug is supposed to work with
> future DPDK release, v18.05.
> --
> 2.14.3
> 
> ___
> 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

[ovs-dev] [PATCH v1] Fix AUTHORS.rst

[lucasagomes]

From: Lucas Alvares Gomes 

The commit 9afc6f14ee7b2622703d98689acb0044d4a5492e added a new author
which name was too long that broke the column size. Runinng "make
docs-checks" was failing because of that.

All this patch does is to enlarge the "Name" column to fit the new
author's name.

Signed-off-by: Lucas Alvares Gomes 
---
 AUTHORS.rst | 688 ++--
 1 file changed, 344 insertions(+), 344 deletions(-)

diff --git a/AUTHORS.rst b/AUTHORS.rst
index c3e34df88..a097370a8 100644
--- a/AUTHORS.rst
+++ b/AUTHORS.rst
@@ -28,351 +28,351 @@ Authors
 The following people authored or signed off on commits in the Open
 vSwitch source code or webpage version control repository.
 
-=== ===
-NameEmail
-=== ===
-Aaron Conoleacon...@redhat.com
-Aaron Rosen aro...@clemson.edu
-Alan Pevec  alan.pe...@redhat.com
-Alexander Duyck alexander.h.du...@redhat.com
-Alexandru Copot alex.miha...@gmail.com
-Alexei Starovoitov  a...@plumgrid.com
-Alexey I. Froloff   ra...@raorn.name
-Alex Wang   ee07b...@gmail.com
-Alfredo Finelli a...@computationes.de
-Alin Balutoiu   abalut...@cloudbasesolutions.com
-Alin Serdeanaserd...@cloudbasesolutions.com
-Ambika Aroraambika.ar...@tcs.com
-Amit Bose   b...@noironetworks.com
-Amitabha Biswas azbis...@gmail.com
-Anand Kumar kumaran...@vmware.com
-Andrew Evansaev...@nicira.com
-Andrew Beekhof  abeek...@redhat.com
-Andrew Kampjes  a.kamp...@gmail.com
-Andrew Lambeth  w...@nicira.com
-Andy Hill   hil...@gmail.com
-Andy Southgate  andy.southg...@citrix.com
-Andy Zhou   az...@ovn.org
-Ankur Sharmaankursha...@vmware.com
-Anoob Soman anoob.so...@citrix.com
-Ansis Attekaaatt...@nicira.com
-Antonio Fischetti   antonio.fische...@intel.com
-Anupam Chanda   acha...@nicira.com
-Ariel Tubaltsev atubalt...@vmware.com
-Arnoldo Lutzarnoldo.lutz.guev...@hpe.com
-Arun Sharma arun.sha...@calsoftinc.com
-Aryan TaheriMonfaredaryan.taherimonfa...@uis.no
-Ashish Varmaashishvarma@gmail.com
-Ashwin Swaminathan  ashwi...@arista.com
-Babu Shanmugam  bscha...@redhat.com
-Ben Pfaff   b...@ovn.org
-Ben Warren  b...@skyportsystems.com
-Benli Yedani...@vmware.com
-Bert Vermeulen  b...@biot.com
-Bhanuprakash Bodireddy  bhanuprakash.bodire...@intel.com
-Billy O'Mahony  billy.o.mah...@intel.com
-Binbin Xu   xu.binb...@zte.com.cn
-Brian Krugerbkruger+ovs...@gmail.com
-Bruce Davie b...@nicira.com
-Bryan Phillippe b...@toroki.com
-Carlo Andreotti c.andreo...@m3s.it
-Casey Barkercrbar...@google.com
-Chandra Sekhar Vejendla csvej...@us.ibm.com
-Christoph Jaegerc...@linux.com
-Chris Wrightchr...@sous-sol.org
-Chuck Short zul...@ubuntu.com
-Ciara Loftusciara.lof...@intel.com
-Clint Byrum cl...@fewbar.com
-Cong Wang   amw...@redhat.com
-Conner Herriges conner.herri...@ibm.com
-Damien Millescamps  damien.millesca...@6wind.com
-Dan Carpenter   dan.carpen...@oracle.com
-Dan McGregordan.mcgre...@usask.ca
-Dan Wendlandt   d...@nicira.com
-Dan Williamsd...@redhat.com
-Daniel Alvarez  dalva...@redhat.com
-Daniel Borkmann dbork...@redhat.com
-Daniel Hiltgen  dan...@netkine.com
-Daniel Romandro...@nicira.com
-Daniele Di Proietto daniele.di.proie...@gmail.com
-Daniele Venturino   venturino.daniele+...@gmail.com
-Danny Kukawka   danny.kuka...@bisect.de
-Darrell Balldlu...@gmail.com
-Dave Tucker d...@dtucker.co.uk
-David Erickson  deric...@stanford.edu
-David Hill  dh...@redhat.com
-David S. Miller da...@davemloft.net
-David Yang  dav...@vmware.com
-Dennis Sam  d...@arista.com
-Devendra Naga   devendra.a...@gmail.com

Re: [ovs-dev] [PATCH] docs: Fix 7 byte octets MAC addresses in dpdk.rst

[Stokes, Ian]

> On Mon, Apr 09, 2018 at 05:18:55PM +0200, Timothy Redaelli wrote:
> > Currently the code relies on the standard 6 byte octets, but the
> > documentation uses a wrong 7-byte octects.
> > This commit fix the documention in order to use the correct 6 byte
> > octets syntax.
> >
> > Fixes: 5e7588186839 ("netdev-dpdk: fix port addition for ports sharing
> > same PCI id")
> >
> > Signed-off-by: Timothy Redaelli 
> 
> I find the use of "byte octets" odd here, since a byte and an octet are
> the same thing.  I would tend to say more like "docs: Fix 7-octet MAC
> addresses".
> 
I agree with above.

> I assume Ian will put this in his next DPDK pull request.

Yes, I intended to have this as part of this week's pull request.

Thanks
Ian
> ___
> 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

[ovs-dev] [PATCH] tc: Change filter error to debug once

[Roi Dayan]

Also update the message to be more correct.
Before this commit if there were tc rules that are not of type
flower the log was getting filled quickyl with errors about it
and always appeared to the user when dumping flows from user space.
This commit moves the error to debug and logs it only once.

Signed-off-by: Roi Dayan 
Reviewed-by: Paul Blakey 
---
 lib/tc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/tc.c b/lib/tc.c
index c446d8407810..8056aeb73385 100644
--- a/lib/tc.c
+++ b/lib/tc.c
@@ -959,7 +959,7 @@ parse_netlink_to_tc_flower(struct ofpbuf *reply, struct 
tc_flower *flower)
 
 kind = nl_attr_get_string(ta[TCA_KIND]);
 if (strcmp(kind, "flower")) {
-VLOG_ERR_RL(_rl, "failed to parse filter: %s", kind);
+VLOG_DBG_ONCE("Unsupported filter: %s", kind);
 return EPROTO;
 }
 
-- 
2.7.0

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

Re: [ovs-dev] [PATCH] Handle gratuitous ARP requests and replies in tnl_arp_snoop()

[Manohar Krishnappa Chidambaraswamy]

Thanx Ben.

-Manu

On 11/04/18, 4:57 AM, "Ben Pfaff"  wrote:

On Thu, Apr 05, 2018 at 12:20:27PM +, Manohar Krishnappa 
Chidambaraswamy wrote:
> Problem:
> 
> In user-space tunneling implementation, tnl_arp_snoop() snoops only ARP
> *reply* packets to resolve tunnel nexthop IP addresses to MAC addresses.
> Normally the ARP requests are periodically sent by the local host IP 
stack,
> so that the ARP cache in OVS is refreshed and entries do not time out.
> However, if the remote tunnel nexthop is a VRRP IP, and the gateway
> periodically sends gratuitous ARP *requests* to announce itself,
> tnl_arp_snoop() treats them as INVALID. Consequently, the ARP cache in OVS
> expires after 10 minutes, which results in dropping of the next packet(s)
> until a new ARP request is responded to.
> 
> Fix:
> 
> Enhance the tunnel neighbor resolution logic in OVS to not only snoop on
> ARP replies but also on gratuitous ARP requests.
> 
> Signed-off-by: Jan Scheurich 
> From: Manohar K C 
> CC: Jan Scheurich 

Thanks, applied to master.


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

Re: [ovs-dev] [PATCH 2/3] ofproto-dpif: Improve dp_hash selection method for select groups

[Jan Scheurich]

Hi Ychen,

Thanks a lot for your tests of corner cases and suggested bug fixes. I will 
include fixes in the next version, possibly also unit test cases for those.

A bucket weight of zero should in my eyes imply no traffic to that bucket. I 
will check how to achieve that.

I will also look into your ofproto_group_unref question.

Regards, Jan


From: ychen [mailto:ychen103...@163.com]
Sent: Wednesday, 11 April, 2018 06:16
To: Jan Scheurich 
Cc: d...@openvswitch.org; Nitin Katiyar 
Subject: Re:[PATCH 2/3] ofproto-dpif: Improve dp_hash selection method for 
select groups

Hi, Jan:
When I test dp_hash with the new patch, vswitchd was killed by segment 
fault in some conditions.
1. add group with no buckets, then winner will be NULL
2. add buckets with weight with 0, then winner will also be NULL

I did little modify to the patch, will you help to check whether it is correct?

diff --git a/ofproto/ofproto-dpif.c b/ofproto/ofproto-dpif.c
index 8f6070d..b3a9639 100755
--- a/ofproto/ofproto-dpif.c
+++ b/ofproto/ofproto-dpif.c
@@ -4773,6 +4773,8 @@ group_setup_dp_hash_table(struct group_dpif *group, 
size_t max_hash)
 webster[i].value = bucket->weight;
 i++;
 }
+//consider bucket weight equal to 0
+if (!min_weight) min_weight = 1;

 uint32_t min_slots = ceil(total_weight / min_weight);
 n_hash = MAX(16, 1L << log_2_ceil(min_slots));
@@ -4794,11 +4796,12 @@ group_setup_dp_hash_table(struct group_dpif *group, 
size_t max_hash)
 for (int hash = 0; hash < n_hash; hash++) {
 VLOG_DBG("Hash value: %d", hash);
 double max_val = 0.0;
-struct webster *winner;
+struct webster *winner = NULL;
 for (i = 0; i < n_buckets; i++) {
 VLOG_DBG("Webster[%d]: divisor=%d value=%.2f",
  i, webster[i].divisor, webster[i].value);
-if (webster[i].value > max_val) {
+// use >= in condition there is only one bucket with weight 0
+if (webster[i].value >= max_val) {
 max_val = webster[i].value;
 winner = [i];
 }
@@ -4827,7 +4830,8 @@ group_set_selection_method(struct group_dpif *group)
 group->selection_method = SEL_METHOD_DEFAULT;
 } else if (!strcmp(selection_method, "dp_hash")) {
 /* Try to use dp_hash if possible at all. */
-if (group_setup_dp_hash_table(group, 64)) {
+uint32_t n_buckets = group->up.n_buckets;
+if (n_buckets && group_setup_dp_hash_table(group, 64)) {
 group->selection_method = SEL_METHOD_DP_HASH;
 group->hash_alg = props->selection_method_param >> 32;
 if (group->hash_alg >= __OVS_HASH_MAX) {


Another question, I found in function xlate_default_select_group and 
xlate_hash_fields_select_group,
when group_best_live_bucket is NULL, it will call ofproto_group_unref,
why dp_hash function no need to call it when there is no best bucket 
found?(exp: group with no buckets)



At 2018-03-21 02:16:17, "Jan Scheurich" 
> wrote:

>The current implementation of the "dp_hash" selection method suffers

>from two deficiences: 1. The hash mask and hence the number of dp_hash

>values is just large enough to cover the number of group buckets, but

>does not consider the case that buckets have different weights. 2. The

>xlate-time selection of best bucket from the masked dp_hash value often

>results in bucket load distributions that are quite different from the

>bucket weights because the number of available masked dp_hash values

>is too small (2-6 bits compared to 32 bits of a full hash in the default

>hash selection method).

>

>This commit provides a more accurate implementation of the dp_hash

>select group by applying the well known Webster method for distributing

>a small number of "seats" fairly over the weighted "parties"

>(see https://en.wikipedia.org/wiki/Webster/Sainte-Lagu%C3%AB_method).

>The dp_hash mask is autmatically chosen large enough to provide good

>enough accuracy even with widely differing weights.

>

>This distribution happens at group modification time and the resulting

>table is stored with the group-dpif struct. At xlation time, we use the

>masked dp_hash values as index to look up the assigned bucket.

>

>If the bucket should not be live, we do a circular search over the

>mapping table until we find the first live bucket. As the buckets in

>the table are by construction in pseudo-random order with a frequency

>according to their weight, this method maintains correct distribution

>even if one or more buckets are non-live.

>

>Xlation is further simplified by storing some derived select group state

>at group construction in struct group-dpif in a form better suited for

>xlation purposes.

>

>Signed-off-by: Jan Scheurich 
>>