st of the other ovs-dpctl commands should not be used under normal
circumstances. Here is what the man page says:
"""
Do not use commands to add or remove or modify datapath flows if
ovs-vswitchd is running because it interferes with ovs-vswitchd's own
datapath flow manageme
o response to inactivity probe after 5 seconds,
> disconnecting
All the logs, except for these ones, can appear under normal circumstances
and do not indicate any real issues on their own. I'm not sure what is
connecting to a local ovsdb-server from the localhost via T
a first match. I've
never seen this particular issue before, but a simple fix might be
to store the output of the ovs-pcap in a file and then grep the file
instead.
Best regards, Ilya Maximets.
>
> 24.05.2023, 23:08, "Ilya Maximets" :
>
> On 5/18/23 11:51
DPDK bridge.
>
>
>
>
>
>
OK. So it was indeed a problem with the memory backend not being shared.
Thanks for the follow up!
Best regards, Ilya Maximets.
> Alex
>
> On 5/26/23, 5:04 AM, "Ilya Maximets" <mailto:i.maxim...@ovn.org>> wrote:
>
>
IFO pipe:[149813]) at ../lib/ovs-thread.c:378 (0% CPU
> usage)
> 2023-05-19T10:48:42.984Z|04589|poll_loop(revalidator64)|DBG|wakeup due to
> [POLLIN] on fd 47 (FIFO pipe:[154649]) at ../lib/ovs-thread.c:378 (1% CPU
> usage)
> 2023-05-19T10:48:42.985Z|13291|poll_loop|DBG|wakeup due to [POLLIN] on fd 56
> (FIFO pipe:[136293]) at ../lib/ovs-rcu.c:236 (2% CPU usage)
> 2023-05-19T10:48:42.999Z|13292|poll_loop|DBG|wakeup due to [POLLIN] on fd 56
> (FIFO pipe:[136293]) at ../lib/ovs-rcu.c:236 (2% CPU usage)
> 2023-05-19T10:48:42.999Z|13293|dpif_netlink|DBG|port_changed:
> dpif:system@ovs-system vport:tap6d5eccfa-06 cmd:2
> 2023-05-19T10:48:42.999Z|13294|dpif|DBG|system@ovs-system: failed to query
> port tap6d5eccfa-06: No such device
>
>
> It seems that OVS successfully add tap device(tap6d5eccfa-06) in br-int, then
> quickly delete the device.
>
> Any idea what’s going on here? Or how to debug in next stage.
Well, it wasn't OVS. Someone/something asked OVS to delete the port:
"ovs-vsctl (invoked by init (pid 0)): ovs-vsctl del-port tap6d5eccfa-06"
Someone/something called ovs-vsctl del-port command.
Best regards, Ilya Maximets.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
inside the VM doesn't dequeue packets for some other reason.
I'd suggest comparing xml files between good and bad setups.
If they are the same - compare command lines of the running QEMU
processes.
And check the QEMU logs. And libvirt logs if there are any.
Best regards, Ilya Maximets.
>
On 5/25/23 14:08, Ales Musil via discuss wrote:
> Hi,
>
> to improve the MAC binding aging mechanism we need a way to ensure that rows
> which are still in use are preserved. This doesn't happen with current
> implementation.
>
> I propose the following solution which should solve the issue,
On 5/25/23 15:35, David Morel wrote:
>> I think, the issue should still be there, though I didn't check.
>> Why exactly porting of the mf_set_mask_l3_prereqs() is a problem?
>> do_xlate_actions() looks different in 2.5.3, but it still performs
>> same mf_are_prereqs_ok() check. Can't you just add
check=yes
> flag, two fell with an error, maybe I still missed some modules when building
> the kernel? I also attached a .config file just in case.
You're missing some userspace tools like tftp.
Not sure why unit tests are failing though.
Best regards, Ilya Maximets.
>
> 09.05.2023,
issue?
Nothing in particular comes to mind. You need to check the logs for warnings
or errors. And check datapath flows installed to see if there is something
abnormal there. Check QEMU logs for vhost user related messages.
If everything looks correct, but there is no traffic, check if you have
shar
ticipate in the
initiative [1] for creation of ovn-heater OpenStack scenarios that
might be close to workloads you have? This way upstream will be able
to test your use-cases or at least something similar.
Most of our current efforts are focused on ovn-kubernetes use-case,
because we don't h
decayed and likely didn't
work anyway.
Can be brought back, if someone is willing to support it.
2.17 is the current LTS and it still has XenServer integration,
I'm not sure if it's working though as I have no way to test it.
[1]
https://github.com/openvswitch/ovs/commit/83c9518e7c67fb73ab17f6db50
On 5/10/23 05:33, 张祖建 wrote:
>
> Attached is the ovn-northd log file.
>
> Numan Siddique mailto:num...@ovn.org>> 于2023年5月10日周三 08:03写道：
>
> On Tue, May 9, 2023 at 1:29 PM Ilya Maximets via discuss
> mailto:ovs-discuss@openvswitch.org>> wrote:
>
also attach the logs of the unit tests. Please, tell me what
> I could do wrong, or what could be wrong?
The unit test failures are strange. Try running with RECHECK=yes.
Best regards, Ilya Maximets.
___
discuss mailing list
disc...@openvswitch.org
htt
It seems to come from this comment:
https://patchwork.ozlabs.org/project/openvswitch/patch/1450463278-7931-4-git-send-email-acon...@redhat.com/#1222040
The idea appears to be that users may want to run OVS completely on
isolated cores and provide them via lcore-mask. In this case we
should no
ing and formatting that is getting rid of bits that are not
part of the mask. And that creates a difference and inability
to remove the address from Sb as a result.
Best regards, Ilya Maximets.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
On 5/3/23 12:47, Vladislav Odintsov wrote:
> Thanks Ilya for your inputs.
>
>> On 2 May 2023, at 21:49, Ilya Maximets wrote:
>>
>> On 5/2/23 19:22, Ilya Maximets wrote:
>>> On 5/2/23 19:04, Vladislav Odintsov via discuss wrote:
>>>> I ran perf record
On 5/2/23 19:22, Ilya Maximets wrote:
> On 5/2/23 19:04, Vladislav Odintsov via discuss wrote:
>> I ran perf record -F99 -p $(ovsdb-server) -- sleep 30 on ovsdb-server
>> process during CPU spike. perf report result:
>>
>
> Could you run it for a couple of minutes du
rf output. It doesn't scale well.
Best regards, Ilya Maximets.
> Samples: 2K of event 'cpu-clock', Event count (approx.): 29989898690
> Overhead Command Shared Object Symbol
> 58.71% ovsdb-server libopenvswitch-3.1.so.0.0.0 [.] uuid_compare_3way
> 7.61% ovsdb-se
you need
to send the wrong packet before sending correct ones.
And you need to look at datapath flows installed in the kernel
with ovs-appctl dpctl/dump-flows.
'ovs-ofctl dump-groups' makes no sense in this context as you're
not using OpenFlow groups.
In general, successful execution of the unit
ing that, especially in 3.1. So, I'm not sure what
exactly is going on in your case. If you can profile the relay
server and see what it is doing all that time, that would be
helpful.
Best regards, Ilya Maximets.
>
> Thanks.
>
> 1: https://mail.openvswitch.org/pipermail/ovs-dev/2023-
for large scale
deployments.
However, if your setup have only one switch with 250 ports and you
have an issue, that should not really be related to scale and you
need to investigate further on what exactly is happening.
Best regards, Ilya Maximets.
On 5/2/23 08:58, Felix Hüttner via discuss wrote:
>
iple different TCP streams at the same time, some
of them should hit the first bucket and some of them the second.
But packets from the same stream should go to the same bucket.
Best regards, Ilya Maximets.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
On 4/25/23 18:50, Terry Wilson wrote:
> On Tue, Apr 25, 2023 at 7:55 AM Ilya Maximets wrote:
>>
>> On 4/25/23 00:12, Terry Wilson via discuss wrote:
>>> A performance issue that has always bothered me:
>>>
>>> OVSDB has a set data type t
actions, otherwise
the kernel will reject the flow. So, you have to push VLAN after
pushing MPLS and pop VLAN after popping MPLS. And that doesn't really
allow you to use VLAN and MPLS together.
I suppose, the original explanation from Jesse still applies
On 4/25/23 17:17, Ilya Maximets wrote:
> On 4/25/23 14:11, Ilya Maximets wrote:
>> On 4/25/23 00:12, Terry Wilson via discuss wrote:
>>> A performance issue that has always bothered me:
>>>
>>> OVSDB has a set data type that matches up with Python's set dat
On 4/25/23 14:11, Ilya Maximets wrote:
> On 4/25/23 00:12, Terry Wilson via discuss wrote:
>> A performance issue that has always bothered me:
>>
>> OVSDB has a set data type that matches up with Python's set data type (an
>> unordered collection of unique items).
d that holds a sorted list.
Clear it when something changes and create a new one whenever user
is accessing the column, but the "parsed" version doesn't exist yet.
It's not ideal, but should be better than what we have now.
This carries the same issue of accidental
filtering large amounts of data and sending it out, not really the
JSON parsing, AFAIK.
Best regards, Ilya Maximets.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
attach/status [bridge]
autoattach/show-isid [bridge]
autoattach/statistics [bridge]
These might give you some information you're looking for, but it's
limited. And there are no other ways to get LLDP-related information
from OVS today.
Best regards, Ilya Maximets.
>
&g
On 4/6/23 19:37, Ilya Maximets wrote:
> Description
> ===
>
> Multiple versions of Open vSwitch are vulnerable to crafted IP packets
> with ip proto set to 0 causing a potential denial of service.
> Triggering the vulnerability will require an attacker to send a c
Description
===
Multiple versions of Open vSwitch are vulnerable to crafted IP packets
with ip proto set to 0 causing a potential denial of service.
Triggering the vulnerability will require an attacker to send a crafted
IP packet with protocol field set to 0 and the flow rules to contain
On 3/31/23 01:14, Vladislav Odintsov wrote:
> Thanks Ilya for such a detailed description about inactivity probes and
> keepalives.
>
> regards,
> Vladislav Odintsov
>
>
>
> regards,
> Vladislav Odintsov
>> On 31 Mar 2023, at 00:37, Ilya Maximets via disc
er without any bidirectional probes is not advisable.
Best regards, Ilya Maximets.
>
>
> Thank you for your help and Terry for his patch!
>
> 1:
> https://patchwork.ozlabs.org/project/openvswitch/patch/20220713030250.2634491-1-twil...@redhat.com/
>
>> On 7 Mar 2023, a
On 1/23/23 11:44, Frode Nordahl wrote:
> On Tue, Jan 3, 2023 at 3:07 PM Ilya Maximets wrote:
>>
>> On 12/14/22 08:28, Frode Nordahl via discuss wrote:
>>> Hello,
>>>
>>> When performing an online schema conversion for a clustered DB the
>>
from the OVS repo). Some features may not be available if they require
newer version of OVS, e.g. ability to flush conntrack entries via
OpenFlow was introduced in OVS 3.1, but all the base functionality
should work just fine.
Best regards, Ilya Maximets.
>
> We are trying out what is the e
uessing that the latter applies to the OVS internal port, i.e.
we probably do not set operational state for them in the kernel. But
that should not affect the traffic in any way as the kernel should
treat the UNKNOWN state more or less the same way as UP.
Best regards, Ilya Maximets.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
On 3/21/23 07:18, Jake Yip wrote:
>
>
> On 20/3/2023 10:51 pm, Ilya Maximets wrote:
>> On 3/16/23 23:06, Jake Yip wrote:
>>> Hi all,
>>>
>>> Apologies for jumping into this thread. We are seeing the same and it's
>>> nice to find someone with
On 3/16/23 23:06, Jake Yip wrote:
> Hi all,
>
> Apologies for jumping into this thread. We are seeing the same and it's nice
> to find someone with similar issues :)
>
> On 8/3/2023 3:43 am, Ilya Maximets via discuss wrote:
>>>>
>>>> We see failures
is alive isn't
really that important for a server, we just need to disconnect
dead clients eventually.
[2]
https://patchwork.ozlabs.org/project/openvswitch/patch/an2a4qcpihpcfukyt1uomqre.1.1641782536691.hmail.wentao@easystack.cn/
Best regards, Ilya Maximets.
___
:04.208Z|00451|stream_ssl|WARN|SSL_read: unexpected SSL
>> connection close
>> 2023-03-06T22:19:04.211Z|00452|reconnect|WARN|ssl:xxx:52590: connection
>> dropped (Protocol error)
OK. These are symptoms. The cause must be something like
'Unreasonably long MANY ms poll interval' on
at triggers inactivity probe failures? Can upgrade to OVS 3.1
solve some of these issues? 3.1 should be noticeably faster than 2.17,
and also parallel compaction introduced in 3.0 removes one of the big
reasons for large poll intervals. OVN upgrade to 22.09+ or even 23.03
should also help with database siz
On 3/1/23 15:24, Brendan Doyle wrote:
>
>
> On 01/03/2023 13:13, Ilya Maximets wrote:
>> On 3/1/23 12:42, Brendan Doyle via discuss wrote:
>>> Hi Folks,
>>>
>>> Whilst launching a lot (150+) of VMs on a hypervisor we occasionally
>>> see error
ovs-vsctl cmd failed :
> ovs-vsctl list-ports br-int | grep vnet87
> vnet87
Database is fine, so the port was added to it without issues, but
ovs-vsctl waits for ovs-vswitchd to act on database update. That
didn't happen within 5 seconds, so ovs-vsctl reported an e
On 2/24/23 06:29, 张祖建 wrote:
> Tried on branch-3.1, branch-2.17, and branch-2.16, and all of them work well.
>
> Thanks very much!
Thanks for testing and confirmation!
Best regards, Ilya Maximets.
>
> Ilya Maximets mailto:i.maxim...@ovn.org>> 于2023年2月24日周五
> 00:41写道
On 2/24/23 01:21, Ilya Maximets wrote:
> On 2/24/23 00:36, Dr. Omran via discuss wrote:
>> is it programmble? i mean: ex. nw_dst!=10.147.20.0/24 ?
>
> No, inequality check is not supported in OpenFlow.
>
>>
>> i misunderstand your example, i think you mean the
rint('priority=200,in_port=enp1s0f0,ip,nw_dst=%s/%s,actions=drop' % (
ipaddress.ip_address((addr & (1 << i)) ^ (1 << i)),
ipaddress.ip_address(1 << i)))
>
>
>
> thank you
>
> kind regards
> Sherif Omran
>
>
>
> On Thu
org/
Would be great if you can try it out.
Best regards, Ilya Maximets.
>
> Ilya Maximets mailto:i.maxim...@ovn.org>> 于2023年2月22日周三
> 03:53写道：
>
> On 2/16/23 02:28, 张祖建 via discuss wrote:
> > Hi all,
> > I'm investigating packet drop
nother
tbale, for example) and have a lower priority rule that doesn't have
a match on nw_dst and drops all the traffic, e.g.:
priority=200,in_port=enp1s0f0,ip,nw_dst=192.168.188.0/24,actions=do_something_else
priority=199,in_port=enp1s0f0,i
re-created on restart.
What version of OVS you have? There was a bug in v2.15.0 that could
cause this kind of behavior.
Best regards, Ilya Maximets.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
On 2/17/23 09:45, Viacheslav Galaktionov wrote:
> On 2/10/23 16:40, Ilya Maximets wrote:
>> On 2/10/23 10:14, Viacheslav Galaktionov wrote:
>>> Thank you!
>>>
>>> Small question, though: what do the n_offload_{packets,bytes} fields
>>>
On 2/16/23 00:36, Tobias Hofmann (tohofman) wrote:
> Thanks Ilya, I can confirm this solves my problem.
Thanks for the confirmation!
Best regards, Ilya Maximets.
>
> Regards
> Tobias
>
> *From: *Ilya Maximets
> *Date: *Wednesday, 15. February 2023 at 14:56
> *To: *
t equal to
the 'other_config:dpdk-socket-mem' to preserve the legacy memory
limiting behavior.
Best regards, Ilya Maximets.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
t packets matching chains which are in_hw. They will not count
flows installed in TC software datapath, but not in HW, AFAICT.
For DPDK, it will count both fully and partially offloaded flows, even
though actions are executed in software for partially offloaded ones.
Best regards, Ilya Maximet
e format. Each transaction can contain
a comment describing who or why executed it. So, if you can find
there a transaction that changes a tag from 100 to 500, it may give
you some more information. Another option is to enable debug logs
for ovsdb-server for the jsonrpc module with:
ovs-appc
_format(results, "n_bytes=%"PRIu64", ", stats.n_bytes);
>
> Am I missing something or am I just the first to need this functionality?
> Maybe
> there's some solution to my problem already and I just don't see it.
Not printing out the cookie value might be just an ov
flow should be in odp_flow
format for that, AFAICT. e.g.:
ovs-appctl ofproto/trace ovs-system
'dp_hash(0xabcd),in_port(1),eth(src=55:55:55:55:55:55,dst=66:66:66:66:66:66),eth_type(0x0800),ipv4(src=192.168.22.1,dst=192.168.22.13,proto=17,tos=0,ttl=255,frag=no),udp(src=23865/0,dst=80)'
and the interface stayed down.
>
> As it turned out this issue got already fixed by Ilya Maximets with
> https://github.com/openvswitch/ovs/commit/bc0aa785a83c11dab482b3e20736b969174d9f86
> ("ovsdb-idl: Fix the database update signaling if it has never been
> connected.")
&g
run as root.
Other than that, it's hard to tell what could have gone
wrong without looking at testsuite logs.
Bets regards, Ilya Maximets.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
If it is though, then I'd highly recommend to update to
at least 2.15.7, or upgrade to the latest 2.17 LTS.
Best regards, Ilya Maximets.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
On 1/8/23 04:51, Han Zhou wrote:
>
>
> On Tue, Jan 3, 2023 at 6:07 AM Ilya Maximets via discuss
> mailto:ovs-discuss@openvswitch.org>> wrote:
>>
>> On 12/14/22 08:28, Frode Nordahl via discuss wrote:
>> > Hello,
>> >
>> > When
It looks like one of the tests is using non-portable '==' extension
for a 'test' shell command. I'll prepare a patch.
Best regards, Ilya Maximets.
>
> Best regards,
> Giovanni
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswit
t,
so don't have any performance data.
All in all the conversion process will be condensed to just two
calls to optimized ovsdb_convert() and two database_destroy().
One before writing to storage and one after reading from it.
This should be enough to cover most of the use cases, I hope.
Thoughts?
On 12/20/22 22:39, Ilya Maximets wrote:
> Description
> ===
>
> Multiple versions of Open vSwitch are vulnerable to crafted LLDP
> packets causing denial of service, and data underflow attacks.
> Triggering the vulnerabilities requires LLDP processing to be enabled
>
On 12/20/22 22:46, John Helmert III wrote:
> On Tue, Dec 20, 2022 at 10:39:23PM +0100, Ilya Maximets wrote:
>> Description
>> ===
>>
>> Multiple versions of Open vSwitch are vulnerable to crafted LLDP
>> packets causing denial of service, and data
Description
===
Multiple versions of Open vSwitch are vulnerable to crafted LLDP
packets causing denial of service, and data underflow attacks.
Triggering the vulnerabilities requires LLDP processing to be enabled
for a specific port. Open vSwitch versions prior to 2.4.0 are not
M_OF_ETH_DST[]->OXM_OF_ETH_SRC[],move:OXM_OF_PKT_REG0[0..47]->OXM_OF_ETH_DST[]
Shorter form might also work:
actions=move:eth_src->xreg0[0..47],move:eth_dst->eth_src[],move:xreg0[0..47]->eth_dst[]
Best regards, Ilya Maximets.
___
discuss mailing list
disc...
On 11/5/22 02:39, Ilya Maximets wrote:
> On 11/4/22 04:01, Thomas Lee via discuss wrote:
>> I'm using OVS 2.17.2, I added a flow:
>>
>> ovs-ofctl add-flow -OOpenflow13 OLT
>> table=22,NXM_NX_REG3[0..16]=65537,reg4=12,actions=learn(table=7,idle_timeout=300,NXM_OF_VLA
witch.org/pipermail/ovs-discuss/2022-November/052099.html
Best regards, Ilya Maximets.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
On 11/1/22 10:50, Eli Britstein wrote:
>
>
>> -Original Message-----
>> From: Ilya Maximets
>> Sent: Monday, 31 October 2022 23:54
>> To: Donald Sharp ; ovs-
>> disc...@openvswitch.org; e...@eecs.berkeley.edu; Eli Britstein
>>
>> Cc: i.ma
es/226
https://github.com/thom311/libnl/issues/224
None of the bugs seems to be resolved. Most are closed for
non-technical reasons.
I suppose, Ethan just decided to not deal with that horribly
unreliable kernel interface and just re-dump the ro
the
interface before setting up the QoS in OVS. But since it is
created by libvirt, it might be hard to do. If it is possible to
tell libvirt to not set custom noqueue qdisc on the interface,
that will also work.
I'll work on the patch to fix the problem from the OVS side.
The change will be si
e xsk.h header from libbpf, but it looks like
kernel's internal xsk.h instead. I'm not sure how you end up
installing that header to the /usr/include/, it should not be there.
If you copied this header from the kernel, undo that.
On Ubuntu you may install libbpf-dev package instead of building
libb
> Hi Dave,
>
> From my knowledge - RHEL has an FDP (Fast Data Path) repository, where those
> packages reside.
> Here are the src rpms:
> https://ftp.redhat.com/pub/redhat/linux/enterprise/8Base/en/Fast-Datapath/SRPMS/
>
>
h, and
> give you feedback.
Thanks!
For now, I think, I'll go ahead and apply the fix, since it was
reviewed and it is more or less obviously correct. But it would
still be great to see a confirmation that it fixes your issue.
Best regards, Ilya Maximets.
>
> Thank you.
>
> -----O
cripts to monitor
OVS events, e.g. count upcalls per interface.
Best regards, Ilya Maximets.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
on after reboot, when DB size
> was 210MB, and started to do compaction again, each 10-20min.
Thanks! I think, I found a 'typo' that caused the issue.
Posted a fix here:
https://patchwork.ozlabs.org/project/openvswitch/patch/20220819230810.2626573-1-i.maxim...@ovn.org/
Would be great if
you're adding
a 'resubmit' action, but with Ryu you're trying to add 'goto_table'
instructions. 'goto_table' must be the last instruction in a flow, so
you can not add more than one of them. The 'resubmit' extension is more
flexible.
I hope that helps.
Best regards, Ilya Maximets.
__
> Hello,
>
> has this feature been integrated into Open vSwitch?
Yes. It was integrated starting with OVS 2.14.
Best regards, Ilya Maximets.
>
> It would be great as I have the following config:
> eth0 = 1 GbE
> eth4 = 10 GbE
> So eth4 should be the primary
ke your application is trying to change the virtio feature
set while device is already running. That is not possible, device
should be stopped first. That generates the protocol error and the port
gets disconnected. Doesn't look like an issue on OVS side.
Best regards, Ilya Maximets
How do you detect that DB is compacting? Are you looking for a message
regarding a leadership transfer or, maybe, reports about time it took
to compact? If you can provide some parts of ovsdb-server logs, that
might also be useful.
Best regards, Ilya Maximets.
_
ed:never,
> actions:set(eth(src=fe:ff:ff:ff:ff:ff,dst=c6:3a:16:ec:e0:d9)),3
>
> compare with the correct datapath flow, dest mac is disappeared in match
> and action.
Hi. The issue you described look very much like the issue fixed in the
following patch:
On 8/1/22 07:57, Nobuhiro MIKI wrote:
> On Fri, Jul 29, 2022 at 02:16:36PM +0200, Ilya Maximets wrote:
>> Unfortunately, I'm not an expert in the kernel tunneling code either.
>> We will likely need a drivers/net/seg6.c or something, with implementation
>> of struct rtn
On 7/29/22 07:44, Nobuhiro MIKI wrote:
> On Thu, Jul 28, 2022 at 03:28:28PM +0200, Ilya Maximets wrote:
>> Hi. Thanks! Sorry, we're in a "release" mode these days, so not much
>> time spent on reviews for new features.
>
> Hi Ilya, Thank you for your reply despi
On 7/28/22 08:16, Nobuhiro MIKI wrote:
> On Thu, Apr 28, 2022 at 04:53:44PM +0900, Nobuhiro MIKI wrote:
>> On Mon, Apr 25, 2022 at 05:59:59PM +0200, Ilya Maximets wrote:
>>> Hi. Sorry for the late reply.
>>>
>>> The feature might be interesting indee
come up with some value. Advertised link
speed sounds like a good enough approximation. You should be
able to avoid the problem by setting the max-rate for the QoS
configuration, if you know the link speed better than kernel.
>
> Now, looking into OpenVSwitch documentation, while not ex
the build. So, if ./configure doesn't fail, you may just
ignore this error. Or try upgrading your compiler. You seem to use
some very old system.
Best regards, Ilya Maximets.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
s "actions=NORMAL". If you want to have load balancing without
using a normal pipeline, you need to implement is yourself, e.g. with creating a
group and having output to that group.
Best regards, Ilya Maximets.
___
discuss mailing list
disc...@op
On 6/14/22 16:26, Oz Shlomo wrote:
> Hi Ilya,
>
> On 6/14/2022 4:03 PM, Ilya Maximets wrote:
>> On 6/14/22 10:27, Oz Shlomo via dev wrote:
>>>
>>>
>>> On 6/8/2022 3:16 AM, Frode Nordahl wrote:
>>>> On Tue, Jun 7, 2022 at 12:16 AM Ilya Maxime
On 6/14/22 10:27, Oz Shlomo via dev wrote:
>
>
> On 6/8/2022 3:16 AM, Frode Nordahl wrote:
>> On Tue, Jun 7, 2022 at 12:16 AM Ilya Maximets wrote:
>>>
>>> On 5/31/22 23:48, Ilya Maximets wrote:
>>>> On 5/31/22 21:15, Frode Nordahl wrote:
>&g
On 5/31/22 23:48, Ilya Maximets wrote:
> On 5/31/22 21:15, Frode Nordahl wrote:
>> On Mon, May 30, 2022 at 5:25 PM Frode Nordahl
>> I've pushed the first part of the fix here:
>> https://mail.openvswitch.org/pipermail/ovs-dev/2022-May/394450.html
>
> Thanks! I s
On 5/31/22 21:15, Frode Nordahl wrote:
> On Mon, May 30, 2022 at 5:25 PM Frode Nordahl
> wrote:
>>
>> On Fri, May 27, 2022 at 10:04 PM Ilya Maximets wrote:
>>>
>>> On 5/26/22 14:53, Frode Nordahl wrote:
>>>>
>>>>
>>>> tor
On 5/26/22 14:53, Frode Nordahl wrote:
>
>
> tor. 26. mai 2022, 14:45 skrev Ilya Maximets <mailto:i.maxim...@ovn.org>>:
>
> On 5/26/22 13:00, Frode Nordahl wrote:
> > On Wed, May 25, 2022 at 9:55 AM Frode Nordahl
> > mailto:fr
On 5/24/22 12:54, Frode Nordahl wrote:
> On Mon, May 23, 2022 at 3:49 PM Ilya Maximets wrote:
>>
>> On 5/21/22 12:49, Frode Nordahl wrote:
>>> On Thu, May 19, 2022 at 3:39 PM Frode Nordahl
>>> wrote:
>>>>
>>>> On Sat, May 14, 2022 at 2
On 5/21/22 12:49, Frode Nordahl wrote:
> On Thu, May 19, 2022 at 3:39 PM Frode Nordahl
> wrote:
>>
>> On Sat, May 14, 2022 at 2:10 AM Ilya Maximets wrote:
>>>
>>> On 5/13/22 10:36, Frode Nordahl wrote:
>>>> On Fri, Mar 11, 2022 at
ar metadata that is internal to
the kernel. Ideas are welcome.
CC: Aaron, Paolo.
Any thoughts?
Best regards, Ilya Maximets.
---
diff --git a/include/openvswitch/ofp-packet.h b/include/openvswitch/ofp-packet.h
index 77128d829..26b07e07f 100644
--- a/include/openvswitch/ofp-packet.h
+++
So, it's better to re-use the common infrastructure.
For the flexible control over SIDs by flow rules, you may achieve that with
options:srv6_sids=flow configuration. For example, see how the remote_ip=flow
or options:erspan_idx=flow are implemented. See the
http://www.openvswitch.org/support/dist-docs/ovs-field
tion inside. 'depth 3'
suggests that it is double nested, i.e. clone(...clone(...ct())) or
clone(...check_pkt_len(...ct())) or something similar. ovs-dpctl
can be used to dump flows.
For now, I'll work on a proper patch for the kernel.
Best regards, Ilya Maximets.
>
> Stéphane
>
>
>
On 2/24/22 20:07, Frode Nordahl wrote:
> On Fri, Apr 9, 2021 at 10:09 PM Ilya Maximets wrote:
>>
>>> Hi all,
>>>
>>> I’m running ovn 20.06.2 with ovs 2.13.0. On some nodes in ovs-vswitchd.log
>>> I see lots of warnings like this:
>>>
>>
d to ignore 'meson' parts of that patch.
That seems to be the only option you have if you want to build with
DPDK on FreeBSD, unfortunately.
Best regards, Ilya Maximets.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
101 - 200 of 275 matches
Mail list logo
