On Fri, Nov 8, 2019 at 6:09 PM Ilya Maximets wrote:
>
> On 08.11.2019 13:12, Numan Siddique wrote:
> > Hi Ilya,
>
> Hi Numan,
>
> Comments inline.
>
> Best regards, Ilya Maximets.
>
> >
> > If you get some time, could you please take a look at this patch ?
> >
> > Thanks
> > Numan
> >
> >
> > On F
On Fri, Nov 8, 2019 at 6:38 AM Dumitru Ceara wrote:
>
> ARP request and ND NS packets for router owned IPs were being
> flooded in the complete L2 domain (using the MC_FLOOD multicast group).
> However this creates a scaling issue in scenarios where aggregation
> logical switches are connected to
There is no log about isolated rxq assignment in a pmd today, which
sometimes could be useful to trace rxq/pmd pinning, when debugging
with log. Ovs-appctl dpif-netdev/pmd-rxq-show reports about it
already, but logging is helpful to trace pinning in time.
Changes:
v3: correction on pmd unref and
Bleep bloop. Greetings Ankur Sharma, I am a robot and I have tried out your
patch.
Thanks for your contribution.
I encountered some error that I wasn't expecting. See the details below.
checkpatch:
WARNING: Line is 117 characters long (recommended limit is 79)
#150 FILE: ovn-sb.xml:1248:
Bleep bloop. Greetings Ankur Sharma, I am a robot and I have tried out your
patch.
Thanks for your contribution.
I encountered some error that I wasn't expecting. See the details below.
checkpatch:
WARNING: Line is 141 characters long (recommended limit is 79)
#42 FILE: Documentation/tutorial
OVN allows only an integer (or masked integer) to be assigned to
ct_mark and ct_label.
This patch, enhances the parser code to allow ct_mark and ct_label
to be assigned from registers as well.
Signed-off-by: Ankur Sharma
---
include/ovn/actions.h | 3 +++
lib/actions.c | 72 +++
OVN ACL implementation used ct_label to indicate if a previosuly
allowed connection should not be allowed anymore and vice versa.
However, ct_label is a 128 bit value and we should rather leverage
on ct_mark which is a 32 bit value.
Using ct_mark for this purpose, allows us to use ct_label for st
This patch allows user to associate a value with acl,
which will be assigned to ct.label of the corresponding
connection tracking entry.
This value can be used to map a ct entry with corresponding
OVN ACL or higher level constructs like security group.
Signed-off-by: Ankur Sharma
---
northd/ovn
I submitted this patch long time back and somehow lost track it.
Resubmitting the series, calling it as V4, as it addresses the
review comments given till v3.
https://mail.openvswitch.org/pipermail/ovs-dev/2019-April/358280.html
What:
a. Goal is to be able to associate some identifier with a
I have tested this patch in linux with ovs version 2.8.2, and it seems worked.
>From fa24d308d40f37f890fead0b79ac1f0f7baa28ba Mon Sep 17 00:00:00 2001
From: hzchenyuefang
Date: Sat, 9 Nov 2019 10:14:23 +0800
Subject: [PATCH 1/1] fix skb_hash problem when sending from internal port
first p
Thanks for the patch
Would you mind describing the use case that this patch is aiming to support
?
On Fri, Nov 8, 2019 at 1:23 AM Zhike Wang wrote:
> Signed-off-by: Zhike Wang
> ---
> lib/conntrack-private.h | 16 ++--
> 1 file changed, 10 insertions(+), 6 deletions(-)
>
> diff --
On 2019-11-08 14:52, Ilya Maximets wrote:
On 06.11.2019 20:20, David Wilder wrote:
Add support for travis-ci ppc64le builds.
- Updated matrix in .travis.yml to include an arch: ppc64le build.
- Move package install needed for 32bit builds to
.travis/linux-prepare.sh.
To keep the total build
On 26.08.2019 16:33, David Marchand wrote:
Add a coverage counter to help diagnose contention on the vhost txqs.
This is seen as dropped packets on the physical ports for rates that
are usually handled fine by OVS.
Signed-off-by: David Marchand
---
Thanks! I changed 'unlikely' to 'OVS_UNLIKEL
On 08.11.2019 9:30, David Marchand wrote:
On Tue, Nov 5, 2019 at 4:37 PM Ilya Maximets wrote:
That's an interesting debug method, but it looks not very suitable
for an end-user documentation. One thing that bothers me the most
is referencing C code snippets in this kind of documentation.
Ok,
On 06.11.2019 20:20, David Wilder wrote:
Add support for travis-ci ppc64le builds.
- Updated matrix in .travis.yml to include an arch: ppc64le build.
- Move package install needed for 32bit builds to .travis/linux-prepare.sh.
To keep the total build time at an acceptable level only a single bui
On Wed, Nov 06, 2019 at 11:20:48AM -0800, David Wilder wrote:
> Add support for travis-ci ppc64le builds.
>
> - Updated matrix in .travis.yml to include an arch: ppc64le build.
> - Move package install needed for 32bit builds to .travis/linux-prepare.sh.
>
> To keep the total build time at an acc
On Fri, Nov 08, 2019 at 05:12:55PM +0100, Matteo Croce wrote:
> Hi,
>
> I need to add a field to enum ovs_action_attr, but I see that the
> definition between the upstream header[1] and the one in compat[2]
> differs.
> Upstream enum stops at OVS_ACTION_ATTR_CHECK_PKT_LEN, with an extra
> "hidden"
The act_ct TC module shares a common conntrack and NAT infrastructure
exposed via netfilter. It's possible that a packet needs both SNAT and
DNAT manipulation, due to e.g. tuple collision. Netfilter can support
this because it runs through the NAT table twice - once on ingress and
again after egr
The openvswitch module shares a common conntrack and NAT infrastructure
exposed via netfilter. It's possible that a packet needs both SNAT and
DNAT manipulation, due to e.g. tuple collision. Netfilter can support
this because it runs through the NAT table twice - once on ingress and
again after e
On Fri, Nov 8, 2019 at 11:22 AM Han Zhou wrote:
>
> 1. storage data and the void *arg of init() breaks the engine node data
encapsulation.
> 2. engine_node_valid(&en_flow_output, engine_run_id) is not needed?
Should use storage to access instead?
> 3. refactor of engine is good but better to be a
1. storage data and the void *arg of init() breaks the engine node data
encapsulation.
2. engine_node_valid(&en_flow_output, engine_run_id) is not needed? Should
use storage to access instead?
3. refactor of engine is good but better to be a separate commit
4. we can have a new interface: engine_ge
Hi Wei
On 2019-11-08 02:02, Yanqin Wei (Arm Technology China) wrote:
Hi David
-Original Message-
From: David Wilder
Sent: Thursday, November 7, 2019 3:21 AM
To: ovs-dev@openvswitch.org
Cc: i.maxim...@ovn.org; b...@ovn.org; Yanqin Wei (Arm Technology China)
; wil...@us.ibm.com
Subject:
26 de Noviembre | Horario de 10:00 a 17:00 hrs. | (hora del centro de México)
- Coaching y liderazgo efectivo. -
El líder coach es un estilo muy completo para utilizar cuando queremos
capacitar a otros y conseguir resultados sólidos a
mediano y largo plazo.
Este webinar tiene como finalidad
Bleep bloop. Greetings Matteo Croce, I am a robot and I have tried out your
patch.
Thanks for your contribution.
I encountered some error that I wasn't expecting. See the details below.
git-am:
fatal: corrupt patch at line 13
Repository lacks necessary blobs to fall back on 3-way merge.
Canno
On 22.10.2019 11:34, Gowrishankar Muthukrishnan wrote:
There is no log about isolated rxq assignment in a pmd today, which
sometimes could be useful to trace rxq/pmd pinning, when debugging
with log. Ovs-appctl dpif-netdev/pmd-rxq-show reports about it
already, but logging is helpful to trace pin
Sorry about that, hopefully this is better (else, I'll just attach it the next
time)
Assuming :Logical Switch (ls1) with ls1_vm1 : 02:ac:10:ff:00:11/172.16.255.11
ls1_vm2 :
02:ac:10:ff:00:22/172.16.255.22 ls1_vm3 :
02:
On 08.11.2019 9:55, Zhike Wang wrote:
If the dev was already probed correctly, the dev attached flag
should be set to true, or resource would leak during destruct.
We're not detaching devices that wasn't attached by us.
If device is already probed in DPDK than it means that most likely it
was
Hi,
I need to add a field to enum ovs_action_attr, but I see that the
definition between the upstream header[1] and the one in compat[2]
differs.
Upstream enum stops at OVS_ACTION_ATTR_CHECK_PKT_LEN, with an extra
"hidden" element after __OVS_ACTION_ATTR_MAX (22)
Our compat version instead, has OV
On 06.11.2019 18:11, Ophir Munk wrote:
Hi Ilya,
A few months ago we discussed the missing functionality of vports offloading
under user space bridges.
Commit [1] was added to explicitly avoid installing userspace vport flows (to
avoid confusion with the vport kernel).
When reverting commit [1]
Add an ovs-appctl command to iterate through the dpcls
and for each subtable output the miniflow bits for any
existing table.
$ ovs-appctl dpif-netdev/subatable-show
pmd thread numa_id 0
dpcls port 2:
subtable:
unit_0: 4 (0x4)
unit_1: 2 (0x2)
pmd thread numa_id 1
dpcls port 3:
On Thu, Nov 7, 2019 at 7:02 PM Dumitru Ceara wrote:
>
> On Thu, Nov 7, 2019 at 6:02 PM Han Zhou wrote:
> >
> >
> >
> > On Thu, Nov 7, 2019 at 7:43 AM Dumitru Ceara wrote:
> > >
> > > On Thu, Nov 7, 2019 at 3:51 AM Han Zhou wrote:
> > > >
> > > >
> > > >
> > > > On Mon, Nov 4, 2019 at 11:32 AM N
ARP request and ND NS packets for router owned IPs were being
flooded in the complete L2 domain (using the MC_FLOOD multicast group).
However this creates a scaling issue in scenarios where aggregation
logical switches are connected to more logical routers (~350). The
logical pipelines of all route
Now netdev-afxdp always forwards all packets to userspace because
it is using libbpf's default XDP program, see 'xsk_load_xdp_prog'.
There are some cases when users want to keep packets in kernel instead
of sending to userspace, for example, management traffic such as SSH
should be processed in ker
On Thu, Nov 07, 2019 at 12:36:33PM +0100, Ilya Maximets wrote:
> Until now there was only two options for XDP mode in OVS: SKB or DRV.
> i.e. 'generic XDP' or 'native XDP with zero-copy enabled'.
>
> Devices like 'veth' interfaces in Linux supports native XDP, but
> doesn't support zero-copy mode.
On Thu, Nov 07, 2019 at 02:28:18PM +0100, Eelco Chaudron wrote:
>
>
> On 7 Nov 2019, at 14:21, Ilya Maximets wrote:
>
> >On 07.11.2019 13:39, Eelco Chaudron wrote:
> >>
> >>
> >>On 7 Nov 2019, at 12:36, Ilya Maximets wrote:
> >>
> >>>Until now there was only two options for XDP mode in OVS: SKB
On 08.11.2019 13:12, Numan Siddique wrote:
Hi Ilya,
Hi Numan,
Comments inline.
Best regards, Ilya Maximets.
If you get some time, could you please take a look at this patch ?
Thanks
Numan
On Fri, Nov 8, 2019 at 4:13 PM wrote:
From: Numan Siddique
The below failure is seen
che
Hi Ilya,
If you get some time, could you please take a look at this patch ?
Thanks
Numan
On Fri, Nov 8, 2019 at 4:13 PM wrote:
>
> From: Numan Siddique
>
> The below failure is seen
>
>
> checking for Python 3 (version 3.4 or later)... /usr/local/bin/python3
> checking where Python six l
Commit eb25a7da639e ("Improve debuggability of OVN to OpenFlow
translations.") added cookies for Port_Binding, Mac_Binding,
Multicast_Group, Chassis records to the OpenfFlow entries they
generate.
Add support for parsing such cookies in ovn-detrace too.
Also, refactor ovn-detrace to allow a more g
After the separation of OVS and OVN rundirs, the ovn-detrace script
hasn't been updated to use the OVN rundir instead of the OVS one.
Signed-off-by: Dumitru Ceara
---
utilities/ovn-detrace.in |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/utilities/ovn-detrace.in b/
The script was never parsing the first cookie in the input. Also, add a
check to make sure that the cookie refers to a Logical_Flow before
trying to print the record.
Signed-off-by: Dumitru Ceara
---
utilities/ovn-detrace.in | 24 ++--
1 file changed, 14 insertions(+), 10 d
Commit eb25a7da639e ("Improve debuggability of OVN to OpenFlow translations.")
added support for more types of cookies (partial SB uuids) that are stored
in OpenFlow entries created by ovn-controller.
The last patch in this series implements support for parsing all these
different cookies in ovn-d
Your email is really cluttered.
Could you please send again with plain text ?
Thanks
Numan
On Fri, Nov 8, 2019 at 6:22 AM venugopal iyer via dev
wrote:
>
> [Pardon the length of the mail; have left out the ofctl flows, but if it
> helps i can send them too]
> Assuming :logical Switch
Bleep bloop. Greetings Numan Siddique, I am a robot and I have tried out your
patch.
Thanks for your contribution.
I encountered some error that I wasn't expecting. See the details below.
checkpatch:
ERROR: Committer Numan Siddique needs to sign off.
Lines checked: 66, Warnings: 0, Errors: 1
On Fri, Nov 8, 2019 at 11:56 AM Numan Siddique wrote:
>
> On Fri, Nov 8, 2019 at 11:22 AM Frode Nordahl
> wrote:
> >
> > Signed-off-by: Frode Nordahl
> > Acked-by: Aliasgar Ginwala
> > Submitted-at: https://github.com/ovn-org/ovn/pull/25
>
> I applied this patch to master.
> Sorry I didn't noti
On Fri, Nov 8, 2019 at 11:22 AM Frode Nordahl
wrote:
>
> Signed-off-by: Frode Nordahl
> Acked-by: Aliasgar Ginwala
> Submitted-at: https://github.com/ovn-org/ovn/pull/25
I applied this patch to master.
Sorry I didn't notice that you already had sent the patch to the ML
and I resubmitted here -
From: Frode Nordahl
Signed-off-by: Frode Nordahl
Acked-by: Aliasgar Ginwala
---
.../topics/role-based-access-control.rst | 7 ++
Documentation/tutorials/ovn-rbac.rst | 25 +++
2 files changed, 32 insertions(+)
diff --git a/Documentation/topics/role-based-acc
From: Numan Siddique
The below failure is seen
checking for Python 3 (version 3.4 or later)... /usr/local/bin/python3
checking where Python six library is available... configure: error: Missing
Python six library.
The command "./.travis/${TRAVIS_OS_NAME}-build.sh $OPTS" exited with 1.
Hi David
> -Original Message-
> From: David Wilder
> Sent: Thursday, November 7, 2019 3:21 AM
> To: ovs-dev@openvswitch.org
> Cc: i.maxim...@ovn.org; b...@ovn.org; Yanqin Wei (Arm Technology China)
> ; wil...@us.ibm.com
> Subject: [PATCH v3] travis: support ppc64le builds
>
> Add support
I guess this is more for Peter or Ingo...
On Thu 07-11-19 19:54:08, syzbot wrote:
> syzbot has found a reproducer for the following crash on:
>
> HEAD commit:99a8efbb NFC: st21nfca: fix double free
> git tree: net
> console output: https://syzkaller.appspot.com/x/log.txt?x=15ed70d8e
Signed-off-by: Zhike Wang
---
lib/conntrack-private.h | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/lib/conntrack-private.h b/lib/conntrack-private.h
index 590f139..1d21f6e 100644
--- a/lib/conntrack-private.h
+++ b/lib/conntrack-private.h
@@ -233,13 +233,1
Set new_proto before it is used in parse_ipv6_ext_hdrs__().
Signed-off-by: Zhike Wang
---
lib/flow.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/flow.c b/lib/flow.c
index a18a1e6..45bb96b 100644
--- a/lib/flow.c
+++ b/lib/flow.c
@@ -1136,11 +1136,11 @@ parse_tcp_flags
If the dev was already probed correctly, the dev attached flag
should be set to true, or resource would leak during destruct.
Signed-off-by: Zhike Wang
---
lib/netdev-dpdk.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
index a65540c..10e2fe9 100644
On 7 Nov 2019, at 17:43, Ilya Maximets wrote:
On 07.11.2019 15:01, Eelco Chaudron wrote:
Any feedback on this?
On 1 Oct 2019, at 11:55, Eelco Chaudron wrote:
Drivers natively supporting AF_XDP will check that a configured MTU
size
will not exceed the allowed size for AF_XDP. However, whe
On Tue, Nov 5, 2019 at 4:37 PM Ilya Maximets wrote:
> >> That's an interesting debug method, but it looks not very suitable
> >> for an end-user documentation. One thing that bothers me the most
> >> is referencing C code snippets in this kind of documentation.
> >
> > Ok, can we conclude on the
On 8 Nov 2019, at 2:34, William Tu wrote:
On Thu, Nov 07, 2019 at 03:01:18PM +0100, Eelco Chaudron wrote:
Any feedback on this?
On 1 Oct 2019, at 11:55, Eelco Chaudron wrote:
Drivers natively supporting AF_XDP will check that a configured MTU
size
will not exceed the allowed size for AF_
55 matches
Mail list logo