On Tue, May 16, 2023 at 7:39 PM Ilya Maximets wrote:
> On 5/16/23 17:46, Ales Musil wrote:
> > To align all relevant branches bump
> > ovs submodule to v3.1.1.
> >
> > Also partially cherry-pick following patch which
> > is required for some changes that happened
> > between the ovs versions.
>
Signed-off-by: Terry Wilson
I can re-send if needed for the sign-off. I've tried to list the
caveats in the commit message/TODO entry. Before I got too far into
digging around into the socket_util and jsonrpc/reconnect code, I
figured I'd put this out there to see if any major changes needed to
Bleep bloop. Greetings Terry Wilson, 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: Author Terry Wilson needs to sign off.
Lines checked: 751, Warnings: 0, Errors: 1
This adds a Python version of the async DNS support added in:
771680d96 DNS: Add basic support for asynchronous DNS resolving
The above version uses the unbound C library, and this
implimentation uses the SWIG-wrapped Python version of that.
In the event that the Python unbound library is not
From: Flavio Leitner
This patch modifies netdev_get_status to include information about
checksum offload status by port, allowing the user to gain insight into
where checksum offloading is active.
Signed-off-by: Flavio Leitner
Co-authored-by: Mike Pattrick
Signed-off-by: Mike Pattrick
From: Flavio Leitner
The netdev receiving packets is supposed to provide the flags
indicating if the L4 checksum was verified and it is OK or BAD,
otherwise the stack will check when appropriate by software.
If the packet comes with good checksum, then postpone the
checksum calculation to the
From: Flavio Leitner
The netdev receiving packets is supposed to provide the flags
indicating if the IP checksum was verified and it is GOOD or BAD,
otherwise the stack will check when appropriate by software.
If the packet comes with good checksum, then postpone the
checksum calculation to the
This patch set is a stripped down subset of the initial 17 patchset introduced
by Flavio Leitner in 2021.
The initial omnibus patchset was very complex and included a refactor, which
stymied review and would have made backporting more complex. It also didn't
resolve an ongoing issue with the DPDK
From: Flavio Leitner
Document the implementation of netdev hardware offloading
in userspace datapath.
Signed-off-by: Flavio Leitner
Co-authored-by: Mike Pattrick
Signed-off-by: Mike Pattrick
---
Since v9:
- Renamed documentation to reflect the userspace checksum nature of
this feature
On Mon, May 15, 2023 at 3:11 PM Ilya Maximets wrote:
>
> On 5/15/23 19:46, Numan Siddique wrote:
> > On Mon, May 15, 2023 at 12:33 PM Ilya Maximets wrote:
> >>
> >> On 5/15/23 18:05, num...@ovn.org wrote:
> >>> From: Numan Siddique
> >>>
> >>> Update the apt cache before installing dependencies
> On Mon, May 15, 2023 at 4:53 PM Lorenzo Bianconi
> wrote:
> >
> > > Hi Lorenzo,
> >
> > Hi Mark,
> >
> > >
> > > This patch and patch 3 both have the same commit message (the top line is
> > > different, but the rest is the same). This doesn't do a good job of
> > > explaining the individual
Hi Vladislav,
Sorry for the late reply.
PSB for few comments.
On Tue, May 16, 2023 at 3:42 PM Vladislav Odintsov wrote:
>
> Hi Numan, Dumitru, Ilya,
>
> I guess I’ve managed to deal with some of these problems and have some
> conclusions.
> Please see inline.
>
> > On 14 Apr 2023, at 16:26,
On 5/16/23 21:48, Vladislav Odintsov wrote:
> Hi Numan, Dumitru, Ilya, Mark,
>
Hi Vladislav,
> if someone can help, I’ll be very grateful.
>
> Thanks in advance.
>
>> On 15 May 2023, at 15:06, Vladislav Odintsov wrote:
>>
>> Hi, I’m implementing neighbour learning on the chassis-redirect
Hi Numan, Dumitru, Ilya, Mark,
if someone can help, I’ll be very grateful.
Thanks in advance.
> On 15 May 2023, at 15:06, Vladislav Odintsov wrote:
>
> Hi,
>
> I’m implementing neighbour learning on the chassis-redirect ports for
> traffic coming from lport of vtep type and have some
On 5/16/23 10:20, Eelco Chaudron wrote:
>
>
> On 15 May 2023, at 17:47, Ilya Maximets wrote:
>
>> On 5/15/23 16:24, Eelco Chaudron wrote:
>>>
>>>
>>> On 4 May 2023, at 0:55, Ilya Maximets wrote:
>>>
On 3/27/23 13:25, Eelco Chaudron wrote:
> Make the read of the current seq->value
Hi Numan, Dumitru, Ilya,
I guess I’ve managed to deal with some of these problems and have some
conclusions.
Please see inline.
> On 14 Apr 2023, at 16:26, Vladislav Odintsov wrote:
>
> And as a follow-up, I see sometimes next error message in ovn-controller log,
> though there is a
tir. 16. mai 2023, 19:03 skrev Ilya Maximets :
> On 5/16/23 17:39, Lazuardi Nasution wrote:
> > Hi,
> >
> > I'm trying to rebuild OVS package by using "dpkg-buildpackage -b"
> command.
> > But the built binary size is always much bigger than repo binary. Is
> there
> > any official way to do that
From: Flavio Leitner
This patch modifies netdev_get_status to include information about
checksum offload status by port, allowing the user to gain insight into
where checksum offloading is active.
Signed-off-by: Flavio Leitner
Co-authored-by: Mike Pattrick
Signed-off-by: Mike Pattrick
From: Flavio Leitner
The netdev receiving packets is supposed to provide the flags
indicating if the L4 checksum was verified and it is OK or BAD,
otherwise the stack will check when appropriate by software.
If the packet comes with good checksum, then postpone the
checksum calculation to the
From: Flavio Leitner
The netdev receiving packets is supposed to provide the flags
indicating if the IP checksum was verified and it is GOOD or BAD,
otherwise the stack will check when appropriate by software.
If the packet comes with good checksum, then postpone the
checksum calculation to the
From: Flavio Leitner
Document the implementation of netdev hardware offloading
in userspace datapath.
Signed-off-by: Flavio Leitner
Co-authored-by: Mike Pattrick
Signed-off-by: Mike Pattrick
---
Since v9:
- Renamed documentation to reflect the userspace checksum nature of
this feature
This patch set is a stripped down subset of the initial 17 patchset introduced
by Flavio Leitner in 2021.
The initial omnibus patchset was very complex and included a refactor, which
stymied review and would have made backporting more complex. It also didn't
resolve an ongoing issue with the DPDK
On 5/16/23 17:46, Ales Musil wrote:
> To align all relevant branches bump
> ovs submodule to v3.1.1.
>
> Also partially cherry-pick following patch which
> is required for some changes that happened
> between the ovs versions.
>
> 1b0dbde94070 ("ovn-controller: Only set monitor conditions on
On 5/16/23 17:39, Lazuardi Nasution wrote:
> Hi,
>
> I'm trying to rebuild OVS package by using "dpkg-buildpackage -b" command.
> But the built binary size is always much bigger than repo binary. Is there
> any official way to do that so the rebuilt binary will be near the repo
> binary?
The
On Wed, May 10, 2023 at 09:11:25PM +0200, Ilya Maximets wrote:
> On 5/9/23 12:05, Stefan Hoffmann wrote:
> > The failed pipeline is bfd-decay again, which seems to fail out of
> > reason sometimes. Test works on my machine.
> >
> > Is there a way to rerun the pipeline?
> >
> >
On Mon, May 08, 2023 at 01:14:55PM +0200, Dumitru Ceara wrote:
> It's not referenced anywhere and by the look of it it has never been.
>
> Signed-off-by: Dumitru Ceara
Reviewed-by: Simon Horman
___
dev mailing list
d...@openvswitch.org
Bleep bloop. Greetings Ales Musil, 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:
error: sha1 information is lacking or useless (tests/ovn.at).
error: could not build fake ancestor
Bleep bloop. Greetings Ales Musil, 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: Unexpected sign-offs from developers who are not authors or co-authors
or committers:
On Fri, May 05, 2023 at 11:40:03AM +0300, Vladislav Odintsov wrote:
> Make it more clear that ovn-monitor-all option has effect on OVN Southbound
> database rather than local OVS.
>
> Reported-at:
> https://mail.openvswitch.org/pipermail/ovs-discuss/2023-May/052421.html
> Reported-by: Ilya
From: Dumitru Ceara
These may change over time and, as a matter of fact, have recently changed
in OVS master branch with commit fcdf8ae4a350 ("lib: Print nw_frag in flow
key.").
Instead, strip the flow key from the output. To achieve that, the calls
to ovn-trace had to go through a bit of
To align all relevant branches bump
ovs submodule to v3.1.1.
Also partially cherry-pick following patch which
is required for some changes that happened
between the ovs versions.
1b0dbde94070 ("ovn-controller: Only set monitor conditions on available
tables.")
In addition pick a test for
From: Dumitru Ceara
This commit also fixes some output issues due to truncated lines
within f-strings or acl log lines that include trailing whitespace
in check_acl_log.py. It also implicitly fixes the flake8 reported
issue:
tests/check_acl_log.py:94:80: E501 line too long (80 > 79
Hi,
I'm trying to rebuild OVS package by using "dpkg-buildpackage -b" command.
But the built binary size is always much bigger than repo binary. Is there
any official way to do that so the rebuilt binary will be near the repo
binary?
Rebuilt Binary:
ubuntu@jammy:~$ ls -lah
Hey Frode, Dumitru, thanks a lot for initiating this
On Thu, May 11, 2023 at 6:05 PM Frode Nordahl
wrote:
> Hello, Dumitru, Daniel and team,
>
> On Thu, May 11, 2023 at 5:23 PM Dumitru Ceara wrote:
> >
> > Hi Frode,
> >
> > During an internal discussion with RedHat OpenStack folks (Daniel in
On 5/16/23 15:14, Ales Musil wrote:
> There was a race within packet buffering that could
> result in first packt being dropped. It could happen
> under following conditions and topology:
> S1 == R1 == public == R2 == S2
> SNAT on R1 and DGP on port connecting R1 with public.
>
> 1) The GARP is
From: Lin Huang
OvS has supported packet-per-second policer which can be set at ingress
and egress side in kernel datapath. But the userspace datapath dosen't
support for ingress and egress packet-per-second policing now.
So, this patch add support for userspace ingress pps policing by using
From: Lin Huang
v4->v3: rewrite egress_policer_details_to_param func.
add a new pkts_policer_profile_config func.
v2->v3: police and free pkts by bulk.
fix the appropriate error code.
v1->v2: delete duplicated code.
Lin Huang (2):
netdev-dpdk: Add support for egress
From: Lin Huang
OvS has supported packet-per-second policer which can be set at ingress
and egress side in kernel datapath. But the userspace datapath doesn't
support for ingress and egress packet-per-second policing now.
So, this patch add support for userspace egress pps policing by using
Bleep bloop. Greetings Ales Musil, 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:
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the
To align all relevant branches bump
ovs submodule to v3.1.1.
Also partially cherry-pick following patch which
is required for some changes that happened
between the ovs versions.
1b0dbde94070 ("ovn-controller: Only set monitor conditions on available
tables.")
Signed-off-by: Ales Musil
---
To align all relevant branches bump
ovs submodule to v3.1.1.
Also partially cherry-pick following patch which
is required for some changes that happened
between the ovs versions.
1b0dbde94070 ("ovn-controller: Only set monitor conditions on available
tables.")
Signed-off-by: Ales Musil
---
To align all relevant branches bump
ovs submodule to v3.1.1.
Signed-off-by: Ales Musil
---
This patch can be applied down to 22.12 without any change.
---
ovs | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ovs b/ovs
index b72a7f925..0187eadfc 16
--- a/ovs
+++ b/ovs
@@
On 5/3/23 22:13, Ihar Hrachyshka wrote:
> Make ICMP Path MTU Discovery flows in table=38 react to underlying
> interface MTU update.
>
> NOTE: ideally, OVN would support Logical_Port MTU, in which case we
> wouldn't have to track OVSDB for interfaces, and we would also be able
> to react to MTU
On 5/3/23 22:13, Ihar Hrachyshka wrote:
> When a multichassis port belongs to a switch with a localnet port,
> packets originating or directed to the multichassis port are NOT sent
> thorugh the localnet port. Instead, tunneling is enforced in-cluster to
> guarantee delivery of all packets to all
On 5/3/23 22:13, Ihar Hrachyshka wrote:
> The new tables will be used in a later patch as follows:
>
> table=37, OFTABLE_OUTPUT_INIT: becomes an initial entry point into the
> egress pipeline that serves a semantic goal. (Not doing any actual
> processing at the moment.)
>
> table=38,
On 5/3/23 22:13, Ihar Hrachyshka wrote:
> This will allow all chassis hosting a port to extract interface MTU from
> if-status-mgr. This will be used in a later patch to calculate the
> effective path MTU for each port.
>
> In addition, it's the right thing to do to claim and mark an interface
>
On 5/3/23 22:13, Ihar Hrachyshka wrote:
> This will be used in a later patch to calculate the effective interface
> MTU after considering tunneling overhead.
>
> Signed-off-by: Ihar Hrachyshka
> ---
> controller/binding.c | 4 ++--
> controller/if-status.c | 31
On 5/3/23 22:13, Ihar Hrachyshka wrote:
> This will be used in a later patch to calculate tunneling overhead for
> effective path MTU.
>
> Signed-off-by: Ihar Hrachyshka
> ---
Looks good to me, thanks!
Acked-by: Dumitru Ceara
___
dev mailing list
There was a race within packet buffering that could
result in first packt being dropped. It could happen
under following conditions and topology:
S1 == R1 == public == R2 == S2
SNAT on R1 and DGP on port connecting R1 with public.
1) The GARP is sent for the DGP SNAT
2) The GARP is delayed on R2
On Tue, May 16, 2023 at 1:29 PM Dumitru Ceara wrote:
> On 5/15/23 12:46, Ales Musil wrote:
> > There was a race within packet buffering that could
> > result in first packt being dropped. It could happen
> > under following conditions and topology:
> > S1 == R1 == public == R2 == S2
> > SNAT on
By default OVS configures 2048 descriptors for tx and rx queues
on DPDK devices. It also allows the user to configure those values.
If the values used are not acceptable to the device then queue setup
would fail.
The device exposes it's max/min/alignment requirements and OVS
applies some limits
There is no need to display 'requested_rx/tx_descriptors' and
'configured_rx/tx_descriptors' as they will be the same.
It is simpler to just have a single 'n_rxq/txq_desc' value.
Suggested-by: Ilya Maximets
Reviewed-by: David Marchand
Signed-off-by: Kevin Traynor
---
lib/netdev-dpdk.c | 10
v4:
- Fixed case where sizes change but limits are not applied (David)
- Use actual device desc sizes to decide to trigger reconfig
- Add log at debug level for case where adjustment has been made but a reconfig
is not
required (i.e. device already configured with adjusted value)
v3:
- Changed
On 10/05/2023 16:19, David Marchand wrote:
On Thu, May 4, 2023 at 7:36 PM Kevin Traynor wrote:
By default OVS configures 2048 descriptors for tx and rx queues
on DPDK devices. It also allows the user to configure those values.
If the values used are not acceptable to the device then queue
On 5/15/23 12:46, Ales Musil wrote:
> There was a race within packet buffering that could
> result in first packt being dropped. It could happen
> under following conditions and topology:
> S1 == R1 == public == R2 == S2
> SNAT on R1 and DGP on port connecting R1 with public.
>
> 1) The GARP is
On 15 May 2023, at 17:47, Ilya Maximets wrote:
> On 5/15/23 16:24, Eelco Chaudron wrote:
>>
>>
>> On 4 May 2023, at 0:55, Ilya Maximets wrote:
>>
>>> On 3/27/23 13:25, Eelco Chaudron wrote:
Make the read of the current seq->value atomic, i.e., not needing to
acquire the global mutex
56 matches
Mail list logo
