In some environments, hardware serving the fabric network doesn't
support double 802.1q (0x8100) VLAN tags, but does support 802.11ad
(0x8a88) EthType for two layer VLAN traffic. Specifically, Cisco
hardware UCS VIC was identified affected by this limitation.
With vlan-passthru=true set for a logi
LGTM
Acked-by: Mark Michelson
On 3/26/21 1:15 PM, Lorenzo Bianconi wrote:
Localports should not be binded to any specific controller but should be
available to each hv however in the current codebase consider_iface_claim
routine is claiming the localport for a specific chassis.
Fix the issue s
Thank you, thank you, thank you for converting the ovn-sb documentation
to XML.
On 3/25/21 7:26 PM, Ben Pfaff wrote:
Also rewrite the manpage and convert it to XML for consistency with
ovn-nbctl, and add tests.
Signed-off-by: Ben Pfaff
---
NEWS | 2 +
manpages.mk
On 3/25/21 7:26 PM, Ben Pfaff wrote:
This rearranges the manpage into a more logical order, documents some
options that weren't documented, adds some sections such as
Environment and Exit Status that a manpage should have, puts the
headings at reasonable levels instead of all at the top level, an
Hi Ben,
I have some comments on the individual patches. In general though, it
seems like 0-day robot has some issues regarding guidelines. You can
probably ignore the warnings about "xxx" comments being present, but the
others looked legitimate to me.
On 3/25/21 7:26 PM, Ben Pfaff wrote:
A
On Mon, Mar 29, 2021 at 05:26:34PM -0500, Ansis Atteka wrote:
> Under high load I observed that Netlink buffer constantly
> fills up for daemons querying Conntrack Table that has a
> lot of entries in it:
>
> netlink_notifier|WARN|netlink receive buffer overflowed
>
> This patch mitigates the pro
Under high load I observed that Netlink buffer constantly
fills up for daemons querying Conntrack Table that has a
lot of entries in it:
netlink_notifier|WARN|netlink receive buffer overflowed
This patch mitigates the problem by increasing socket
receive buffer size. Ideally we should try to cal
Thanks Mark and Dumitru for the reviews. I've addressed almost all the comments
and submitted v5. Request to please take a look.
Please see a few comments inline below.
Thanks
Numan
On Thu, Mar 25, 2021 at 6:52 PM Dumitru Ceara wrote:
>
> On 3/23/21 4:55 PM, num...@ovn.org wrote:
> > From: N
From: Alexey Roytman
Signed-off-by: Alexey Roytman
---
tests/ovs-vsctl.at | 5 +
1 file changed, 5 insertions(+)
diff --git a/tests/ovs-vsctl.at b/tests/ovs-vsctl.at
index d2cb41403..6fbe6da49 100644
--- a/tests/ovs-vsctl.at
+++ b/tests/ovs-vsctl.at
@@ -1483,6 +1483,11 @@ AT_CHECK([RUN_OVS
From: Alexey Roytman
Signed-off-by: Alexey Roytman
---
lib/db-ctl-base.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/lib/db-ctl-base.c b/lib/db-ctl-base.c
index e95c77da2..77cc76a9f 100644
--- a/lib/db-ctl-base.c
+++ b/lib/db-ctl-base.c
@@ -1823,6 +1823,11 @@ cmd_destroy(struct ctl
From: Alexey Roytman
OVSDB CLI utilities (ovs-vsctl, ovn-nbctl and ovn-sbctl) allow destroying
the entire table or some records from the given table.
However, either the --all option or the deleted records should be provided.
These patches add the test.
Changes since v1:
- replace ctl_error by
I have the it cleaned up and it is stable on the machine where I could
reproduce your issue.
It was all in the exit sequence. That is why the testsuite was green - crashes
were after all processing was complete.
I will clean it up, run it overnight for a final test and if it's all OK send a
n
From: Numan Siddique
When a port binding type changes from type 'A' to type 'B', then
there are many code paths in the existing binding.c which results
in crashes due to use-after-free or NULL references.
Below crashes are seen when a container lport is changed to a normal
lport and then deleted
On 2021/3/25, 11:30 PM, "Mark Gray" wrote:
On 19/03/2021 13:01, Dumitru Ceara wrote:
> On 3/10/21 2:29 PM, gmingchen(陈供明) wrote:
>> From: Gongming Chen
>>
Thanks for the patch. Looks like a lot of thought went into the
algorithm and it has been interesting to review.
On 24 Mar 2021, at 14:03, Chris Mi wrote:
On 3/24/2021 8:14 PM, Ilya Maximets wrote:
On 3/24/21 10:17 AM, Chris Mi wrote:
On 3/23/2021 10:24 PM, Ilya Maximets wrote:
On 3/5/21 4:27 AM, Chris Mi wrote:
Hi Ilya,
I think about your suggestion recently. But I'm still not very
clear about the
On Mon, Mar 29, 2021 at 2:45 PM Numan Siddique wrote:
>
>
> On Mon, Mar 29, 2021 at 2:10 PM Frode Nordahl
> wrote:
>
>> On Thu, Mar 25, 2021 at 2:39 PM Frode Nordahl
>> wrote:
>> >
>> > On Wed, Mar 24, 2021 at 2:32 PM Frode Nordahl
>> > wrote:
>> > >
>> > > On Wed, Mar 24, 2021 at 1:54 PM Numa
On Mon, Mar 29, 2021 at 2:10 PM Frode Nordahl
wrote:
> On Thu, Mar 25, 2021 at 2:39 PM Frode Nordahl
> wrote:
> >
> > On Wed, Mar 24, 2021 at 2:32 PM Frode Nordahl
> > wrote:
> > >
> > > On Wed, Mar 24, 2021 at 1:54 PM Numan Siddique wrote:
> > > > I applied the patches 6 and 7 to the main bra
On Thu, Mar 25, 2021 at 2:39 PM Frode Nordahl
wrote:
>
> On Wed, Mar 24, 2021 at 2:32 PM Frode Nordahl
> wrote:
> >
> > On Wed, Mar 24, 2021 at 1:54 PM Numan Siddique wrote:
> > > I applied the patches 6 and 7 to the main branch.
> > >
> > > There are some issues with patch 9. I didn't apply pa
On 3/28/21 3:01 AM, Mark Michelson wrote:
> On 3/26/21 10:12 AM, Dumitru Ceara wrote:
>> On 3/26/21 2:52 PM, Mark Michelson wrote:
>>> On 3/26/21 7:35 AM, Dumitru Ceara wrote:
On 3/26/21 12:32 PM, Dumitru Ceara wrote:
> On 3/24/21 12:44 AM, Mark Michelson wrote:
>> On 3/23/21 6:55 PM,
On 3/28/21 8:46 AM, Han Zhou wrote:
> On Fri, Mar 26, 2021 at 5:37 AM Dumitru Ceara wrote:
>>
>> In large scale deployments it's expected that there are many port
>> bindings. Out of these only a small fraction is usually a
>> localnet/l2gateway port.
>>
>> Instead of iterating on all SB port bin
On 3/28/21 8:30 AM, Han Zhou wrote:
> On Fri, Mar 26, 2021 at 1:12 AM Mark Gray wrote:
>>
>> On 25/03/2021 14:56, Dumitru Ceara wrote:
>>> Spotted during code inspection.
>>>
>>> Signed-off-by: Dumitru Ceara
>>> ---
>>> controller/lflow.c | 6 +++---
>>> 1 file changed, 3 insertions(+), 3 deleti
21 matches
Mail list logo