On Wed, Feb 10, 2021 at 8:57 PM Eli Britstein wrote:
>
> Support tunnel pop action.
>
> Signed-off-by: Eli Britstein
> Reviewed-by: Gaetan Rivet
> ---
> Documentation/howto/dpdk.rst | 1 +
> NEWS | 1 +
> lib/netdev-offload-dpdk.c| 173 +++
On 2/24/2021 7:36 AM, Sriharsha Basavapatna wrote:
On Wed, Feb 10, 2021 at 8:57 PM Eli Britstein wrote:
Recover the packet if it was partially processed by the HW. Fallback to
lookup flow by mark association.
Signed-off-by: Eli Britstein
Reviewed-by: Gaetan Rivet
---
lib/dpif-netdev.c |
On Wed, Feb 10, 2021 at 8:57 PM Eli Britstein wrote:
>
> Recover the packet if it was partially processed by the HW. Fallback to
> lookup flow by mark association.
>
> Signed-off-by: Eli Britstein
> Reviewed-by: Gaetan Rivet
> ---
> lib/dpif-netdev.c | 46 ++-
Fix the following ovs-dpdk crash:
$ ovs-appctl dpctl/add-flow "eth(),eth_type(0x0800),ipv4()" "3"
unixctl|WARN|error communicating with
unix:/usr/local/var/run/openvswitch/ovs-vswitchd.1995.ctl: End of file
ovs-appctl: ovs-vswitchd: transaction error (End of file)
ovs-vswitchd.log record:
util(
Out of curious, I remember OVN doesn't support OVS DPDK, I believe OVN also
does IPv6 ND by openflow, is it acceptable to use slow path to handle IPv6 ND
for OVS kernel datapath?
-邮件原件-
发件人: Yi Yang (杨燚)-云服务集团
发送时间: 2021年2月24日 9:56
收件人: 'u9012...@gmail.com'
抄送: 'f...@sysclose.org' ; 'b
Thanks, got it, I'll add this to kernel data path if nobody did it.
-邮件原件-
发件人: William Tu [mailto:u9012...@gmail.com]
发送时间: 2021年2月24日 2:31
收件人: Yi Yang (杨燚)-云服务集团
抄送: f...@sysclose.org; b...@ovn.org; ovs-dev@openvswitch.org;
ovs-disc...@openvswitch.org
主题: Re: [ovs-discuss] Do you kno
On Tue, Feb 23, 2021, at 22:55, William Tu wrote:
> On Wed, Feb 17, 2021 at 8:34 AM Gaetan Rivet wrote:
> >
> > The current rate limit is set to allow other threads to update the
> > connections when applicable. This was valid when taking the 'ct_lock'
> > was needed with a global critical sect
On Tue, Feb 23, 2021, at 22:56, William Tu wrote:
> On Wed, Feb 17, 2021 at 8:34 AM Gaetan Rivet wrote:
> >
> > When ct_sweep() is far behind on its work, the 'next_wake' returned can
> > be before the moment it started. When it happens, the thread schedules a
> > zero ms timer that is logged as a
On Tue, Feb 23, 2021, at 22:55, William Tu wrote:
> Thanks, I have one question inline.
>
> On Wed, Feb 17, 2021 at 8:34 AM Gaetan Rivet wrote:
> >
> > Change the data structure from hmap to cmap for zone limits.
> > As they are shared amongst multiple conntrack users, multiple
> > readers want t
On Tue, Feb 23, 2021, at 22:55, William Tu wrote:
> Hi Gaetan,
>
> Thanks for the patch, looks very useful.
> I haven't tested it yet.
> Minor question/comments inline.
Hi William, thanks for taking a look!
[...]
> >
> > +/* Timeouts: all the possible timeout states passed to update_expiratio
On Wed, Feb 17, 2021 at 8:34 AM Gaetan Rivet wrote:
>
> A lock is taken during conn_lookup() to check whether a connection is
> expired before returning it. This lock can have some contention.
>
> Even though this lock ensures a consistent sequence of writes, it does
> not imply a specific order.
On Wed, Feb 17, 2021 at 8:34 AM Gaetan Rivet wrote:
>
> When ct_sweep() is far behind on its work, the 'next_wake' returned can
> be before the moment it started. When it happens, the thread schedules a
> zero ms timer that is logged as an error.
>
> Instead, mark the thread for immediate wake in
On Wed, Feb 17, 2021 at 8:34 AM Gaetan Rivet wrote:
>
> The current rate limit is set to allow other threads to update the
> connections when applicable. This was valid when taking the 'ct_lock'
> was needed with a global critical section.
>
> Now that the size of the critical section for 'ct_lock
On Wed, Feb 17, 2021 at 8:34 AM Gaetan Rivet wrote:
>
> Do not add noise to the DBG log for empty sweeps.
> Only log time taken when some connections were cleaned.
>
> Signed-off-by: Gaetan Rivet
> Reviewed-by: Eli Britstein
> ---
LGTM
Acked-by: William Tu
> lib/conntrack.c | 6 --
> 1
On Wed, Feb 17, 2021 at 8:34 AM Gaetan Rivet wrote:
>
> The lock priority order is for the global 'ct_lock' to be taken first
> and then 'conn->lock'. This is an issue, as multiple operations on
> connections are thus blocked between threads contending on the
> global 'ct_lock'.
>
> This was previ
On Wed, Feb 17, 2021 at 8:34 AM Gaetan Rivet wrote:
>
> Multiple lookups are done to stored timeout policies, each time blocking
> the global 'ct_lock'. This is usually not necessary and it should be
> acceptable to get policy updates slightly delayed (by one RCU sync
> at most). Using a CMAP redu
Thanks, I have one question inline.
On Wed, Feb 17, 2021 at 8:34 AM Gaetan Rivet wrote:
>
> Change the data structure from hmap to cmap for zone limits.
> As they are shared amongst multiple conntrack users, multiple
> readers want to check the current zone limit state before progressing in
> the
On Wed, Feb 17, 2021 at 8:34 AM Gaetan Rivet wrote:
>
> The 'hash_basis' field is used sometimes during sub-systems init
> routine. It will be 0 by default before randomization. Sub-systems would
> then init some nodes with incorrect hash values.
>
> The timeout policies module is affected, making
Hi Gaetan,
Thanks for the patch, looks very useful.
I haven't tested it yet.
Minor question/comments inline.
On Wed, Feb 17, 2021 at 8:34 AM Gaetan Rivet wrote:
>
> Change the connection expiration lists from ovs_list to rculist.
> This is a pre-step towards reducing the granularity of 'ct_lock'
On Tue, Feb 23, 2021 at 11:16 PM Ben Pfaff wrote:
>
> On Tue, Feb 23, 2021 at 07:38:12PM +0530, Numan Siddique wrote:
> > On Tue, Feb 23, 2021 at 4:10 PM Numan Siddique wrote:
> > >
> > > On Fri, Feb 19, 2021 at 4:10 AM Ben Pfaff wrote:
> > > >
> > > > This passed in the ovsrobot CI:
> > > > htt
> >>> +
> >>> +return 0;
> >>> +}
> >>> +#endif
> >>> +
> >>> static int
> >>> xsk_load_prog(struct netdev *netdev, const char *path,
> >>> struct bpf_object **pobj, int *prog_fd)
> >>> {
> >>> +struct netdev_linux *dev OVS_UNUSED = netdev_linux_cast(netdev);
> >>>
On 23/02/2021 14:12, Lorenzo Bianconi wrote:
>> On 22/02/2021 12:15, Lorenzo Bianconi wrote:
>>
>> Thanks Lorenzo, I think the change to unixctl commands looks good. Some
>> more comments below.
>
> Hi Mark,
>
> thx for the review
Thanks for taking my review comments into consideration!
>
>>
>>
On 23/02/2021 14:52, Lorenzo Bianconi wrote:
> Introduce inc-engine/show-stats ovs-appctl command in order to dump
> ovn-controller incremental processing engine statistics. So far for each
> node a counter for run, abort and engine_handler have been added.
> Counters are incremented when the node
> >>> I don't know if this is too much to ask for.
> >>> I wonder if you, or we can work together, to add at least a tunnel
> >>> support, ex: vxlan?
> >>> The current version is a good prototype for people to test an L2/L3
> >>> XDP offload switch,
> >>> but without a good use case, it's hard to a
On Sun, Feb 21, 2021 at 9:39 PM Yi Yang (杨燚)-云服务集团 wrote:
>
> Thanks William, it is my ovs-ofctl issue, my ovs-vswitchd is new, but
> ovs-ofctl is old, but after I used ovs-ofctl, I still saw issues:
>
> OFPT_ERROR (OF1.3) (xid=0x6): OFPBAC_BAD_SET_ARGUMENT
> OFPT_FLOW_MOD (OF1.3) (xid=0x6): ADD
ovsdb_cs_send_transaction() returns the pointer to the same
'request_id' object that is used internally. This leads to
situation where transaction in idl and CS module has the
same 'request_id' object. However, CS module is able to
destroy this transaction id at any time, e.g. if connection
state
On Tue, Feb 23, 2021 at 07:38:12PM +0530, Numan Siddique wrote:
> On Tue, Feb 23, 2021 at 4:10 PM Numan Siddique wrote:
> >
> > On Fri, Feb 19, 2021 at 4:10 AM Ben Pfaff wrote:
> > >
> > > This passed in the ovsrobot CI:
> > > https://github.com/ovsrobot/ovn/actions/runs/579307688
> > >
> > > I t
On 2/23/21 2:55 PM, Ilya Maximets wrote:
> ovsdb_cs_send_transaction() returns the pointer to the same
> 'request_id' object that is used internally. This leads to
> situation where transaction in idl and CS module has the
> same 'request_id' object. However, CS module is able to
> destroy this t
Introduce inc-engine/show-stats ovs-appctl command in order to dump
ovn-controller incremental processing engine statistics. So far for each
node a counter for run, abort and engine_handler have been added.
Counters are incremented when the node move to "updated" state.
In order to dump I-P stats w
On Tue, Feb 23, 2021 at 7:38 PM Numan Siddique wrote:
>
> On Tue, Feb 23, 2021 at 4:10 PM Numan Siddique wrote:
> >
> > On Fri, Feb 19, 2021 at 4:10 AM Ben Pfaff wrote:
> > >
> > > This passed in the ovsrobot CI:
> > > https://github.com/ovsrobot/ovn/actions/runs/579307688
> > >
> > > I think th
> On 22/02/2021 12:15, Lorenzo Bianconi wrote:
>
> Thanks Lorenzo, I think the change to unixctl commands looks good. Some
> more comments below.
Hi Mark,
thx for the review
>
> > Introduce inc-engine/stats ovs-applctl command in order to dump
>
> nit: inc-engine/show-stats or clear-stats?
>
On Tue, Feb 23, 2021 at 4:10 PM Numan Siddique wrote:
>
> On Fri, Feb 19, 2021 at 4:10 AM Ben Pfaff wrote:
> >
> > This passed in the ovsrobot CI:
> > https://github.com/ovsrobot/ovn/actions/runs/579307688
> >
> > I think that we have arrived at consensus to push this to ovn master
> > after bran
ovsdb_cs_send_transaction() returns the pointer to the same
'request_id' object that is used internally. This leads to
situation where transaction in idl and CS module has the
same 'request_id' object. However, CS module is able to
destroy this transaction id at any time, e.g. if connection
state
On 2/23/2021 3:10 PM, Sriharsha Basavapatna wrote:
On Wed, Feb 10, 2021 at 8:57 PM Eli Britstein wrote:
A miss in virtual port offloads means the flow with tnl_pop was
offloaded, but not the following one. Recover the state and continue
with SW processing.
Relates to my comment on Patch-1; p
On 2/23/2021 3:35 PM, Sriharsha Basavapatna wrote:
On Tue, Feb 23, 2021 at 5:14 PM Eli Britstein wrote:
On 2/23/2021 12:48 PM, Sriharsha Basavapatna wrote:
On Sun, Feb 21, 2021 at 7:04 PM Eli Britstein wrote:
On 2/18/2021 6:38 PM, Kovacevic, Marko wrote:
External email: Use caution openi
On Tue, Feb 23, 2021 at 5:14 PM Eli Britstein wrote:
>
>
> On 2/23/2021 12:48 PM, Sriharsha Basavapatna wrote:
> > On Sun, Feb 21, 2021 at 7:04 PM Eli Britstein wrote:
> >>
> >> On 2/18/2021 6:38 PM, Kovacevic, Marko wrote:
> >>> External email: Use caution opening links or attachments
> >>>
> >>
On 2/23/2021 3:10 PM, Sriharsha Basavapatna wrote:
On Wed, Feb 10, 2021 at 8:57 PM Eli Britstein wrote:
When offloading vports, we don't configure rte_flow on the vport itself,
as it is not a physical dpdk port, but rather on uplinks. Implement
those APIs as a pre-step to enable iterate over
On 2/23/2021 3:10 PM, Sriharsha Basavapatna wrote:
On Wed, Feb 10, 2021 at 8:57 PM Eli Britstein wrote:
When the HW offload involves multiple flows, like in tunnel decap path,
it is possible that not all flows in the path are offloaded, resulting
in partial processing in HW. In order to proce
Matching on ct.dnat creates openflows that often are not offloadable
to hardware. ovn-northd uses ct.dnat only for load balancer hairpin
traffic handling and it turns out we don't really need to match on
ct.dnat.
Signed-off-by: Dumitru Ceara
---
northd/ovn-northd.8.xml | 32 +++---
Matching on ct_nw_dst()/ct_ipv6_dst()/ct_tp_dst() creates openflows
that often are not offloadable to hardware. This was used for
detecting load balancer hairpin sessions.
However, it can be avoided if ovn-northd stores the original
destination tuple in OVS registers. For backwards compatibility
If two load balancer VIPs share the same backend, both sets of hairpin
reply learn() flows should be generated. In order to ensure that,
also match on the original destination IP and port tuple. These are
now stored in OVS registers by ovn-northd in stage ls-in-stateful.
An alternative solution
Patch 1/3 fixes a bug when using learn() action to generate hairpin
reply flows for different VIPs that share backends. It also addresses
backwards compatibility in order to avoid having issues during upgrades.
Patches 2/3 and 3/3 use the new OVS registers populated by patch 1/3 to
simplify the h
This command will stop sending and receiving any RAFT-related
traffic or accepting new connections. Useful to simulate
network problems between cluster members.
There is no unit test that uses it yet, but it's convenient for
manual testing.
Signed-off-by: Ilya Maximets
---
ovsdb/raft.c | 31 ++
If election times out for a server in 'candidate' role it sets
'candidate_retrying' flag that notifies that storage is disconnected
and client should re-connect. However, cluster/status command
reports 'Status: cluster member' and that is misleading.
Reporting "disconnected from the cluster (elect
It's not enough to just have heartbeats.
RAFT heartbeats are unidirectional, i.e. leader sends them to followers
but not the other way around. Missing heartbeats provokes followers to
start election, but if leader will not receive any replies it will not
do anything while there is a quorum, i.e.
On Wed, Feb 10, 2021 at 8:57 PM Eli Britstein wrote:
>
> A miss in virtual port offloads means the flow with tnl_pop was
> offloaded, but not the following one. Recover the state and continue
> with SW processing.
Relates to my comment on Patch-1; please explain what is meant by
recovering the pa
On Wed, Feb 10, 2021 at 8:57 PM Eli Britstein wrote:
>
> When offloading vports, we don't configure rte_flow on the vport itself,
> as it is not a physical dpdk port, but rather on uplinks. Implement
> those APIs as a pre-step to enable iterate over the ports.
We don't need these flow_dump APIs,
On Wed, Feb 10, 2021 at 8:57 PM Eli Britstein wrote:
>
> When the HW offload involves multiple flows, like in tunnel decap path,
> it is possible that not all flows in the path are offloaded, resulting
> in partial processing in HW. In order to proceed with rest of the
> processing in SW, the pack
On 2/22/21 2:05 PM, 贺鹏 wrote:
> Hi, Ilya and William,
>
> Ilya Maximets 于2021年2月22日周一 下午8:12写道：
>>
>> On 2/21/21 5:11 PM, William Tu wrote:
>>> On Fri, Feb 19, 2021 at 6:29 PM 贺鹏 wrote:
Hi, Ilya
Ilya Maximets 于2021年2月19日周五 下午7:19写道：
>
> On 2/19/21 3:12 AM, 贺鹏 wrote:
On 2/19/21 1:09 AM, William Tu wrote:
> On Wed, Feb 17, 2021 at 1:09 PM Yifeng Sun wrote:
>>
>> ovs-vswitchd could crash under these circumstances:
>> 1. When one bridge is being destroyed, ofproto_destroy() is called and
>> connmgr pointer of its ofproto struct is nullified. This ofproto struct i
On Tue, Feb 23, 2021 at 4:56 PM Dumitru Ceara wrote:
>
> On 2/22/21 7:48 PM, num...@ovn.org wrote:
> > From: Numan Siddique
> >
> > In one of the scaled deployments, ovn-controller is asserting with the
> > below stack trace
> >
> > ***
> > (gdb) bt
> > 0 raise () from /lib64/
On 2/23/2021 1:38 PM, Kovacevic, Marko wrote:
External email: Use caution opening links or attachments
<...>
Sending to Marko. As he wasn't subscribed to ovs-dev then.
<...>
VXLAN decap in OVS-DPDK configuration consists of two flows:
F1: in_port(ens1f0),eth(),ipv4(),udp(), actions:tnl_p
> On 19/02/2021 14:26, Lorenzo Bianconi wrote:
> > Introduce inc-engine/stats ovs-applctl command in order to dump
> > ovn-controller incremental processing engine statistics. So far for each
> > node a counter for run, abort and engine_handler have been added.
> > Counters are incremented when the
On 2/23/2021 12:48 PM, Sriharsha Basavapatna wrote:
On Sun, Feb 21, 2021 at 7:04 PM Eli Britstein wrote:
On 2/18/2021 6:38 PM, Kovacevic, Marko wrote:
External email: Use caution opening links or attachments
<...>
Sending to Marko. As he wasn't subscribed to ovs-dev then.
<...>
VXLAN
> >
> >
> > <...>
> >> Sending to Marko. As he wasn't subscribed to ovs-dev then.
> >>
> > <...>
> >>> VXLAN decap in OVS-DPDK configuration consists of two flows:
> >>> F1: in_port(ens1f0),eth(),ipv4(),udp(), actions:tnl_pop(vxlan_sys_4789)
> >>> F2: tunnel(),in_port(vxlan_sys_4789),eth(),ipv4(),
On 2/22/21 7:48 PM, num...@ovn.org wrote:
From: Numan Siddique
In one of the scaled deployments, ovn-controller is asserting with the
below stack trace
***
(gdb) bt
0 raise () from /lib64/libc.so.6
1 abort () from /lib64/libc.so.6
2 ovs_abort_valist ("%s:
On 23 Feb 2021, at 12:11, Eelco Chaudron wrote:
On 23 Feb 2021, at 10:08, Roi Dayan wrote:
On 2021-01-27 8:23 AM, Chris Mi wrote:
This patch set adds offload support for sFlow.
Psample is a genetlink channel for packet sampling. TC action
act_sample
uses psample to send sampled packets
On 23 Feb 2021, at 10:08, Roi Dayan wrote:
On 2021-01-27 8:23 AM, Chris Mi wrote:
This patch set adds offload support for sFlow.
Psample is a genetlink channel for packet sampling. TC action
act_sample
uses psample to send sampled packets to userspace.
When offloading sample action to TC
On Fri, Feb 19, 2021 at 10:52 PM Numan Siddique wrote:
>
> On Fri, Feb 19, 2021 at 8:56 PM Mark Michelson wrote:
> >
> > Signed-off-by: Mark Michelson
>
> For both the patches in the series
> Acked-by: Numan Siddique
Hi Mark,
Since we were supposed to create the branch on 19th Feb, I went ahe
On Sun, Feb 21, 2021 at 7:04 PM Eli Britstein wrote:
>
>
> On 2/18/2021 6:38 PM, Kovacevic, Marko wrote:
> > External email: Use caution opening links or attachments
> >
> >
> > <...>
> >> Sending to Marko. As he wasn't subscribed to ovs-dev then.
> >>
> > <...>
> >>> VXLAN decap in OVS-DPDK confi
On Fri, Feb 19, 2021 at 4:10 AM Ben Pfaff wrote:
>
> This passed in the ovsrobot CI:
> https://github.com/ovsrobot/ovn/actions/runs/579307688
>
> I think that we have arrived at consensus to push this to ovn master
> after branching happens tomorrow. Please, let me know if I
> misunderstood!
I t
On 2021-01-27 8:23 AM, Chris Mi wrote:
This patch set adds offload support for sFlow.
Psample is a genetlink channel for packet sampling. TC action act_sample
uses psample to send sampled packets to userspace.
When offloading sample action to TC, userspace creates a unique ID to
map sFlow ac
62 matches
Mail list logo
