Re: [ovs-dev] INSTRUCTION TO RELEASE YOUR PENDING FUND.
I.M.F ) Head Office Paris Office 64-66, Avenue d'lena 75116 Paris, France Tel:+33757906502 REF:-XVGNN82020 INSTRUCTION TO RELEASE YOUR PENDING FUND. Attention: This is to intimate you of a very important information which will be of a great help to redeem you from all the difficulties you have been experiencing in getting your long over due payment due to excessive demand for money from you by both corrupt Bank officials and Courier Companies after which your fund remain unpaid to you. I am Mr.Jeffrey Franks a highly placed official of the International Monetary Fund (IMF). It may interest you to know that reports have reached our office by so many correspondences on the uneasy way which people like you are treated by Various Banks and Courier Companies/ Diplomat across Europe to Africa and Asia /London Uk and we have decided to put a stop to that and that is why I was appointed to handle your transaction here in U/K and U.S.A All Governmental and Non-Governmental prostates, NGOs, Finance Companies,Banks, Security Companies and Courier companies which have been in contact with you of late have been instructed to back up from your transaction and you have been advised NOT to respond to them anymore since the IMF is now directly in charge of your payment. The most annoying thing is that the bad officials wont tell you the truth that on no account will they ever release the fund to you, instead they allow you spend money unnecessarily, I do not intend to work here all the days of my life, I can release this fund to you if you can certify me of my security. I hope this is clear. Any action contrary to this instruction is at your own risk. Respond to this e-mail on (franksmrjeffre...@gmail.com ) with immediate effect and we shall give you further details on how your fund will be released. 1.Full Name:. 2.Address:.. 3.Nationality:.. 4.Age:Date of Birth:... 5.Occupation: 6.Phone:...Mobile: .: ... 7.State of Origin:..Country:. 8. Copy of your identity Card Yours sincerely, Jeffrey Franks ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH net-next v3] openvswitch: add TTL decrement action
On Wed, Jan 15, 2020 at 8:40 AM Matteo Croce wrote:
>
> New action to decrement TTL instead of setting it to a fixed value.
> This action will decrement the TTL and, in case of expired TTL, drop it
> or execute an action passed via a nested attribute.
> The default TTL expired action is to drop the packet.
>
> Supports both IPv4 and IPv6 via the ttl and hop_limit fields, respectively.
>
> Tested with a corresponding change in the userspace:
>
> # ovs-dpctl dump-flows
> in_port(2),eth(),eth_type(0x0800), packets:0, bytes:0, used:never,
> actions:dec_ttl{ttl<=1 action:(drop)},1
> in_port(1),eth(),eth_type(0x0800), packets:0, bytes:0, used:never,
> actions:dec_ttl{ttl<=1 action:(drop)},2
> in_port(1),eth(),eth_type(0x0806), packets:0, bytes:0, used:never,
> actions:2
> in_port(2),eth(),eth_type(0x0806), packets:0, bytes:0, used:never,
> actions:1
>
> # ping -c1 192.168.0.2 -t 42
> IP (tos 0x0, ttl 41, id 61647, offset 0, flags [DF], proto ICMP (1),
> length 84)
> 192.168.0.1 > 192.168.0.2: ICMP echo request, id 386, seq 1, length 64
> # ping -c1 192.168.0.2 -t 120
> IP (tos 0x0, ttl 119, id 62070, offset 0, flags [DF], proto ICMP (1),
> length 84)
> 192.168.0.1 > 192.168.0.2: ICMP echo request, id 388, seq 1, length 64
> # ping -c1 192.168.0.2 -t 1
> #
>
Thanks for the patch.
> Co-developed-by: Bindiya Kurle
> Signed-off-by: Bindiya Kurle
> Signed-off-by: Matteo Croce
> ---
> include/uapi/linux/openvswitch.h | 2 +
> net/openvswitch/actions.c| 67 ++
> net/openvswitch/flow_netlink.c | 71
> 3 files changed, 140 insertions(+)
>
> diff --git a/include/uapi/linux/openvswitch.h
> b/include/uapi/linux/openvswitch.h
> index ae2bff14e7e1..9d3f040847af 100644
> --- a/include/uapi/linux/openvswitch.h
> +++ b/include/uapi/linux/openvswitch.h
> @@ -958,6 +958,7 @@ enum ovs_action_attr {
> OVS_ACTION_ATTR_CLONE,/* Nested OVS_CLONE_ATTR_*. */
> OVS_ACTION_ATTR_CHECK_PKT_LEN, /* Nested OVS_CHECK_PKT_LEN_ATTR_*. */
> OVS_ACTION_ATTR_ADD_MPLS, /* struct ovs_action_add_mpls. */
> + OVS_ACTION_ATTR_DEC_TTL, /* Nested OVS_DEC_TTL_ATTR_*. */
>
> __OVS_ACTION_ATTR_MAX,/* Nothing past this will be accepted
>* from userspace. */
> @@ -1050,4 +1051,5 @@ struct ovs_zone_limit {
> __u32 count;
> };
>
> +#define OVS_DEC_TTL_ATTR_EXEC 0
I am not sure if we need this, But if you want the nested attribute
then lets define enum with this single attribute and have actions as
part of its data. This would be optional argument, so userspace can
skip it, and in that case datapath can drop the packet.
> #endif /* _LINUX_OPENVSWITCH_H */
> diff --git a/net/openvswitch/actions.c b/net/openvswitch/actions.c
> index 7fbfe2adfffa..1b0afc9bf1ad 100644
> --- a/net/openvswitch/actions.c
> +++ b/net/openvswitch/actions.c
> @@ -964,6 +964,26 @@ static int output_userspace(struct datapath *dp, struct
> sk_buff *skb,
> return ovs_dp_upcall(dp, skb, key, , cutlen);
> }
>
> +static int dec_ttl(struct datapath *dp, struct sk_buff *skb,
> + struct sw_flow_key *key,
> + const struct nlattr *attr, bool last)
Can you give it better name, for example: dec_ttl_exception_handler().
> +{
> + /* The first action is always 'OVS_DEC_TTL_ATTR_ARG'. */
> + struct nlattr *dec_ttl_arg = nla_data(attr);
> + u32 nested = nla_get_u32(dec_ttl_arg);
> + int rem = nla_len(attr);
> +
> + if (nested) {
> + struct nlattr *actions = nla_next(dec_ttl_arg, );
> +
> + if (actions)
> + return clone_execute(dp, skb, key, 0, actions, rem,
> +last, false);
> + }
> + consume_skb(skb);
> + return 0;
> +}
> +
> /* When 'last' is true, sample() should always consume the 'skb'.
> * Otherwise, sample() should keep 'skb' intact regardless what
> * actions are executed within sample().
> @@ -1180,6 +1200,45 @@ static int execute_check_pkt_len(struct datapath *dp,
> struct sk_buff *skb,
> nla_len(actions), last, clone_flow_key);
> }
>
> +static int execute_dec_ttl(struct sk_buff *skb, struct sw_flow_key *key)
> +{
> + int err;
> +
> + if (skb->protocol == htons(ETH_P_IPV6)) {
> + struct ipv6hdr *nh;
> +
> + err = skb_ensure_writable(skb, skb_network_offset(skb) +
> + sizeof(*nh));
> + if (unlikely(err))
> + return err;
> +
> + nh = ipv6_hdr(skb);
> +
> + if (nh->hop_limit <= 1)
> + return -EHOSTUNREACH;
> +
> + key->ip.ttl = --nh->hop_limit;
> + } else {
> + struct iphdr *nh;
> + u8 old_ttl;
> +
> +
Re: [ovs-dev] [PATCH ovn 0/2] Caching logical flow expr tree for each lflow
For the series: Acked-by: Mark Michelson I think the speedup is commendable. Great job! That being said, I'm surprised it wasn't better. Do you know, with this patch applied, what the hit rate is for the cache? And assuming the hit rate is high, do you know what the new bottleneck in add_logical_flows() is? On 1/9/20 12:36 PM, num...@ovn.org wrote: From: Numan Siddique This patch series tries to improve the time taken to proceess logical flows by caching the expr tree. For large scale deployments with lots of logical flows, the logical flow processing to OpenFlow rules takes a lot of time as it is CPU intensive. This patch series tries to improve this by caching the expr tree generated for each logical flow so that we don't have to generate the expr tree for each lflow_run(). Below are the details of the OVN resource in my setup No of logical switches - 49 No of logical ports- 1191 No of logical routers - 7 No of logical ports- 51 No of ACLs - 1221 No of Logical flows- 664736 On a chassis hosting 7 distributed router ports and around 1090 port bindings, the no of OVS rules was 921162. Without this patch, the function add_logical_flows() took ~15 seconds. And with this patch it took ~10 seconds. There is a good 34% improvement in logical flow processing. Numan Siddique (2): expr: Evaluate the condition expression in a separate step. ovn-controller: Cache logical flow expr tree for each lflow. controller/lflow.c | 181 +++- controller/lflow.h | 9 +- controller/ovn-controller.c | 17 +++- include/ovn/expr.h | 10 +- lib/expr.c | 55 --- tests/test-ovn.c| 10 +- utilities/ovn-trace.c | 5 +- 7 files changed, 212 insertions(+), 75 deletions(-) ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v5 1/2] netdev-dpdk: Add support for multi-queue QoS to the DPDK datapath
On 14.01.2020 17:12, Eelco Chaudron wrote: > This patch adds support for multi-queue QoS to the DPDK datapath. Small nit: Please, don't use term 'DPDK datapath' in the future. There is no such thing in OVS. Best regards, Ilya Maximets. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] cirrus: Use python 3.7 packages on FreeBSD.
On 03.01.2020 13:40, Ilya Maximets wrote: > On 02.01.2020 19:33, Ben Pfaff wrote: >> On Thu, Jan 02, 2020 at 01:08:40PM +0100, Ilya Maximets wrote: >>> Python 3.6 versions of these packages are no longer available in >>> FreeBSD ports. >>> >>> Signed-off-by: Ilya Maximets >> >> Acked-by: Ben Pfaff > > Thanks! Applied to master and backported to 2.12. Backported also to 2.11. I didn't do that last time for unknown reason. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] Connecting
Hi, Would you be interested in email database of *Security and Cyber Security Professionals?* We can help you reach out to. The database is inclusive of the complete contact details and verified email address of all key decision makers. *Industry Specification:* IT, Medical & Healthcare, Home Care & Hospice, Oil & Gas, Mining, Utility, Industrial, Hospitality, Educational, Retail, Commercial, Government, Construction, Safety and Security, Interior design, Telecom, Signage, Technology Users, Audio & Video, Manufacturing, Transportation, Engineering, Natural Gas, Fitness & Health, Chemical, Environment, Food and Beverage, Packaging, Education, Retail, Aerospace, Defense, Automotive and many more. Please share your *target criteria below*. Upon your confirmation, I will get back to you with the counts/cost and other information’s. *Target **Industry* *:__? Target Job Title:__? Target Geography:__?* Looking forward to your response. Best Regards, *Emma A. Joshua**Marketing Executive* ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] INFO: task hung in ovs_vport_cmd_del
Hello, syzbot found the following crash on: HEAD commit:555089fd bpftool: Fix printing incorrect pointer in btf_du.. git tree: bpf console output: https://syzkaller.appspot.com/x/log.txt?x=1790e421e0 kernel config: https://syzkaller.appspot.com/x/.config?x=609c965f105b4789 dashboard link: https://syzkaller.appspot.com/bug?extid=d6f697f97a60a6430fa7 compiler: gcc (GCC) 9.0.0 20181231 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+d6f697f97a60a6430...@syzkaller.appspotmail.com INFO: task syz-executor.0:1552 blocked for more than 143 seconds. Not tainted 5.5.0-rc4-syzkaller #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. syz-executor.0 D27912 1552 9613 0x4004 Call Trace: context_switch kernel/sched/core.c:3385 [inline] __schedule+0x934/0x1f90 kernel/sched/core.c:4081 schedule+0xdc/0x2b0 kernel/sched/core.c:4155 schedule_preempt_disabled+0x13/0x20 kernel/sched/core.c:4214 __mutex_lock_common kernel/locking/mutex.c:1033 [inline] __mutex_lock+0x7ab/0x13c0 kernel/locking/mutex.c:1103 mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1118 ovs_lock net/openvswitch/datapath.c:105 [inline] ovs_vport_cmd_del+0x77/0x770 net/openvswitch/datapath.c:2227 genl_family_rcv_msg_doit net/netlink/genetlink.c:672 [inline] genl_family_rcv_msg net/netlink/genetlink.c:717 [inline] genl_rcv_msg+0x67d/0xea0 net/netlink/genetlink.c:734 netlink_rcv_skb+0x177/0x450 net/netlink/af_netlink.c:2477 genl_rcv+0x29/0x40 net/netlink/genetlink.c:745 netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline] netlink_unicast+0x58c/0x7d0 net/netlink/af_netlink.c:1328 netlink_sendmsg+0x91c/0xea0 net/netlink/af_netlink.c:1917 sock_sendmsg_nosec net/socket.c:639 [inline] sock_sendmsg+0xd7/0x130 net/socket.c:659 sys_sendmsg+0x753/0x880 net/socket.c:2330 ___sys_sendmsg+0x100/0x170 net/socket.c:2384 __sys_sendmsg+0x105/0x1d0 net/socket.c:2417 __do_sys_sendmsg net/socket.c:2426 [inline] __se_sys_sendmsg net/socket.c:2424 [inline] __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2424 do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x45af49 Code: e8 3c 1f 00 00 eb aa cc cc cc cc cc cc cc cc cc cc 64 48 8b 0c 25 f8 ff ff ff 48 3b 61 10 76 40 48 83 ec 28 48 89 6c 24 20 48 <8d> 6c 24 20 48 8b 42 10 48 8b 4a 18 48 8b 52 08 48 89 14 24 48 89 RSP: 002b:7fbec8448c78 EFLAGS: 0246 ORIG_RAX: 002e RAX: ffda RBX: 0003 RCX: 0045af49 RDX: RSI: 2000 RDI: 0003 RBP: 0075bf20 R08: R09: R10: R11: 0246 R12: 7fbec84496d4 R13: 004ca99c R14: 004e3e08 R15: INFO: task syz-executor.0:1554 blocked for more than 143 seconds. Not tainted 5.5.0-rc4-syzkaller #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. syz-executor.0 D27912 1554 9613 0x4004 Call Trace: context_switch kernel/sched/core.c:3385 [inline] __schedule+0x934/0x1f90 kernel/sched/core.c:4081 schedule+0xdc/0x2b0 kernel/sched/core.c:4155 schedule_preempt_disabled+0x13/0x20 kernel/sched/core.c:4214 __mutex_lock_common kernel/locking/mutex.c:1033 [inline] __mutex_lock+0x7ab/0x13c0 kernel/locking/mutex.c:1103 mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1118 ovs_lock net/openvswitch/datapath.c:105 [inline] ovs_vport_cmd_del+0x77/0x770 net/openvswitch/datapath.c:2227 genl_family_rcv_msg_doit net/netlink/genetlink.c:672 [inline] genl_family_rcv_msg net/netlink/genetlink.c:717 [inline] genl_rcv_msg+0x67d/0xea0 net/netlink/genetlink.c:734 netlink_rcv_skb+0x177/0x450 net/netlink/af_netlink.c:2477 genl_rcv+0x29/0x40 net/netlink/genetlink.c:745 netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline] netlink_unicast+0x58c/0x7d0 net/netlink/af_netlink.c:1328 netlink_sendmsg+0x91c/0xea0 net/netlink/af_netlink.c:1917 sock_sendmsg_nosec net/socket.c:639 [inline] sock_sendmsg+0xd7/0x130 net/socket.c:659 sys_sendmsg+0x753/0x880 net/socket.c:2330 ___sys_sendmsg+0x100/0x170 net/socket.c:2384 __sys_sendmsg+0x105/0x1d0 net/socket.c:2417 __do_sys_sendmsg net/socket.c:2426 [inline] __se_sys_sendmsg net/socket.c:2424 [inline] __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2424 do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x45af49 Code: e8 3c 1f 00 00 eb aa cc cc cc cc cc cc cc cc cc cc 64 48 8b 0c 25 f8 ff ff ff 48 3b 61 10 76 40 48 83 ec 28 48 89 6c 24 20 48 <8d> 6c 24 20 48 8b 42 10 48 8b 4a 18 48 8b 52 08 48 89 14 24 48 89 RSP: 002b:7fbec8427c78 EFLAGS: 0246 ORIG_RAX: 002e RAX: ffda RBX: 0003 RCX: 0045af49 RDX: RSI: 2000 RDI: 0003 RBP:
Re: [ovs-dev] [PATCH v5 2/2] netdev-dpdk: Add new DPDK RFC 4115 egress policer
On 1/15/2020 4:49 PM, Kevin Traynor wrote: On 15/01/2020 13:19, Stokes, Ian wrote: On 1/15/2020 12:19 PM, Ilya Maximets wrote: On 15.01.2020 12:28, Stokes, Ian wrote: On 1/14/2020 4:12 PM, Eelco Chaudron wrote: This patch adds a new policer to the DPDK datapath based on RFC 4115's Two-Rate, Three-Color marker. It's a two-level hierarchical policer which first does a color-blind marking of the traffic at the queue level, followed by a color-aware marking at the port level. At the end traffic marked as Green or Yellow is forwarded, Red is dropped. For details on how traffic is marked, see RFC 4115. This egress policer can be used to limit traffic at different rated based on the queues the traffic is in. In addition, it can also be used to prioritize certain traffic over others at a port level. For example, the following configuration will limit the traffic rate at a port level to a maximum of 2000 packets a second (64 bytes IPv4 packets). 100pps as CIR (Committed Information Rate) and 1000pps as EIR (Excess Information Rate). High priority traffic is routed to queue 10, which marks all traffic as CIR, i.e. Green. All low priority traffic, queue 20, is marked as EIR, i.e. Yellow. ovs-vsctl --timeout=5 set port dpdk1 qos=@myqos -- \ --id=@myqos create qos type=trtcm-policer \ other-config:cir=52000 other-config:cbs=2048 \ other-config:eir=52000 other-config:ebs=2048 \ queues:10=@dpdk1Q10 queues:20=@dpdk1Q20 -- \ --id=@dpdk1Q10 create queue \ other-config:cir=4160 other-config:cbs=2048 \ other-config:eir=0 other-config:ebs=0 -- \ --id=@dpdk1Q20 create queue \ other-config:cir=0 other-config:cbs=0 \ other-config:eir=4160 other-config:ebs=2048 \ This configuration accomplishes that the high priority traffic has a guaranteed bandwidth egressing the ports at CIR (1000pps), but it can also use the EIR, so a total of 2000pps at max. These additional 1000pps is shared with the low priority traffic. The low priority traffic can use at maximum 1000pps. Thanks for the patch Eelco, minor comment below. Ok, with the below discussion in mind I've pushed the series master. The understanding is that a better approach will be sought so that we can remove the experimental API exception in the future. I can raise this with the DPDK community call tomorrow and see what possibilities we have for removing the tag. If in the meantime, a new feature is submitted for OVS with DPDK that has an experimental tag for an API call it will be pushed back on until the experimental tag is removed. Thanks Ian Rate Limiting (Ingress Policing) diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c index 128963f..1ed4a47 100644 --- a/lib/netdev-dpdk.c +++ b/lib/netdev-dpdk.c @@ -26,6 +26,12 @@ #include #include +/* Include rte_compat.h first to allow experimental API's needed for the + * rte_meter.h rfc4115 functions. Once they are no longer marked as + * experimental the #define and rte_compat.h include can be removed. + */ +#define ALLOW_EXPERIMENTAL_API +#include I guess the risk here, from what I understand, this approach is all or nothing in terms of experimental APIs from the included headers, other experimental APIs could be used from DPDK going forward without causing warning? If so, there would have to be extra dilligence taken when reviewing future patches and a discussion if an API is expereimental, should it wait until it is marked as non experimental. (In this case The TRTCM looks stable and is highly unlikey to be removed so it's not an issue IMO). @Ilya/Kevin: Would you agree with above? Thoughts? I think it make sense to wait for API to become non-experimental if we have no easy way to enable it only on functions we need. I agree that having widly enabled experimental api might produce additional issues and will require more careful review of all the DPDK related patches. So I'm ok with making an exception in this case for the feature, I think it was an oversight but the API is stable. But what I'm hearing is in general the rule should be for new features the API should not be experimental and if it is then it would have to have it's experimental tag removed by the next DPDK upgrade (in this case 20.11 for arguments sake) and then can be upstreamed to OVS master. In this case, it sounds ok to me. We know it will be non-experimental in the next hours/days and we will not be left with some zombie feature on upgrade. Plus, there might be an acceptable way of adding a non-experimental symbol for this to the v19.11 stable branch too (not guaranteed though), and if so we could turn this off on upgrade to v19.11.X. OTOH, I don't know how important it is to have this feature in OVS 2.13. > BTW, another thought I have in mind about all the release management is: Shouldn't we hold OVS updates to new DPDK LTS until the first correction release is out? I mean, for example, Ubuntu triggers updates from one
Re: [ovs-dev] [PATCH] netdev-offload-tc: Fix crash if offloading is not configured on outdev.
On 14.01.2020 21:48, Ben Pfaff wrote:
> On Tue, Jan 14, 2020 at 09:30:17PM +0100, Ilya Maximets wrote:
>> If output device is not yet added to netdev-offload, netdev_ports_get()
>> will not find it leading to NULL pointer dereference inside
>> netdev_get_inindex().
>>
>> Fixes: 8f283af89298 ("netdev-tc-offloads: Implement netdev flow put using tc
>> interface")
>> Signed-off-by: Ilya Maximets
>
> Acked-by: Ben Pfaff
>
Thanks! Applied to master and backported.
Best regards, Ilya Maximets.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH V7 10/18] dpif-netdev: Update offloaded flows statistics
On 09.01.2020 08:46, Eli Britstein wrote:
> From: Ophir Munk
>
> In case a flow is HW offloaded, packets do not reach the SW, thus not
> counted for statistics. Use netdev flow get API in order to update the
> statistics of flows by the HW statistics.
>
> Co-authored-by: Eli Britstein
> Signed-off-by: Ophir Munk
> Reviewed-by: Oz Shlomo
> Signed-off-by: Eli Britstein
> ---
> lib/dpif-netdev.c | 79
> ++-
> 1 file changed, 66 insertions(+), 13 deletions(-)
>
> diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
> index 24218210d..7ec217f39 100644
> --- a/lib/dpif-netdev.c
> +++ b/lib/dpif-netdev.c
> @@ -3030,10 +3030,49 @@ dp_netdev_pmd_find_flow(const struct
> dp_netdev_pmd_thread *pmd,
> return NULL;
> }
>
> +static bool
> +dpif_netdev_get_flow_offload_status(const struct dp_netdev *dp,
> +const struct dp_netdev_flow *netdev_flow,
> +struct dpif_flow_stats *stats,
> +struct dpif_flow_attrs *attrs)
> +{
> +struct nlattr *actions;
> +struct ofpbuf wbuffer;
> +struct netdev *netdev;
> +struct match match;
> +
> +int ret = 0;
> +
> +if (!netdev_is_flow_api_enabled()) {
> +return false;
> +}
> +
> +netdev = netdev_ports_get(netdev_flow->flow.in_port.odp_port, dp->class);
> +if (!netdev) {
> +return false;
> +}
> +/* Taking a global 'port_mutex' to fulfill thread safety
> + * restrictions for the netdev-offload-dpdk module. */
> +ovs_mutex_lock(>port_mutex);
Found a bug with taking a mutex here.
Please, take a look at the fix: https://patchwork.ozlabs.org/patch/1223746/
Ian, I'd like to here your opinion on the fix too, if possible.
Best regards, Ilya Maximets.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH] dpif-netdev: Make datapath port mutex recursive.
Upcoming HW offloading will request flow statistics from the dpdk offloading module. This operation requires holding datapath port mutex. However, there is a possible scenarion in which flow deletion happens during datapath reconfiguration process and the mutex already acquired: 0 raise () from /lib64/libc.so.6 1 abort () from /lib64/libc.so.6 2 ovs_abort_valist () 3 ovs_abort () 4 ovs_mutex_lock_at () 5 dpif_netdev_get_flow_offload_status () 6 get_dpif_flow_status () 7 flow_del_on_pmd () 8 dpif_netdev_flow_del () 9 dpif_netdev_operate () 10 dpif_operate () 11 push_dp_ops () 12 push_ukey_ops () 13 dp_purge_cb () 14 dp_netdev_del_pmd () 15 reconfigure_pmd_threads () 16 reconfigure_datapath () 17 do_del_port () 18 dpif_netdev_port_del () 19 dpif_port_del () 20 port_del () 21 ofproto_port_del () 22 bridge_delete_or_reconfigure_ports () 23 bridge_reconfigure () 24 bridge_run () 25 main () This happens while removing the last port of a particular PMD thread. Reconfiguration process decides that we need to remove current PMD thread and calls datapath purge callback in order to clean up resources assigned to it. This turns into flow removal and flow_del() tries to request statistics. Turning the dp->mutex into recursive version as a quick fix for this issue. Better solutions might be to avoid statistics request somehow, or fully disassociate offloaded flows from the datapath flows. Signed-off-by: Ilya Maximets --- Ideas for better solution are welcome. lib/dpif-netdev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c index 079bd1bdf..d4b1ebbff 100644 --- a/lib/dpif-netdev.c +++ b/lib/dpif-netdev.c @@ -1547,7 +1547,7 @@ create_dp_netdev(const char *name, const struct dpif_class *class, ovs_refcount_init(>ref_cnt); atomic_flag_clear(>destroyed); -ovs_mutex_init(>port_mutex); +ovs_mutex_init_recursive(>port_mutex); hmap_init(>ports); dp->port_seq = seq_create(); fat_rwlock_init(>upcall_rwlock); -- 2.17.1 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [v3] dpif-netdev: Modified ovs-appctl dpctl/dump-flows command
On 15.01.2020 17:19, Emma Finn wrote:
> Modified ovs-appctl dpctl/dump-flows command to output
> the miniflow bits for a given flow when -m option is passed.
>
> $ ovs-appctl dpctl/dump-flows -m
>
> Signed-off-by: Emma Finn
>
> ---
>
> RFC -> v1
>
> * Changed revision from RFC to v1
> * Reformatted based on comments
> * Fixed same classifier being dumped multiple times
> flagged by Ilya
> * Fixed print of subtables flagged by William
> * Updated print count of bits as well as bits themselves
>
> ---
>
> v1 -> v2
>
> * Reformatted based on comments
> * Refactored code to make output part of ovs-appctl
> dpctl/dump-flows -m command.
>
> ---
>
> v2 -> v3
>
> * Added attribute dp_extra_info to dpif_flow_attrs struct
> to store miniflow bits as a string
> ---
> NEWS | 2 ++
> lib/dpctl.c | 4
> lib/dpif-netdev.c | 8
> lib/dpif.h| 1 +
> 4 files changed, 15 insertions(+)
>
> diff --git a/NEWS b/NEWS
> index 965faca..1c9d2db 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -8,6 +8,8 @@ Post-v2.12.0
> * Add option to enable, disable and query TCP sequence checking in
> conntrack.
> * Add support for conntrack zone limits.
> + * Command "ovs-appctl dpctl/dump-flows" refactored to show subtable
> + miniflow bits for userspace datapath.
> - AF_XDP:
> * New option 'use-need-wakeup' for netdev-afxdp to control enabling
> of corresponding 'need_wakeup' flag in AF_XDP rings. Enabled by
> default
> diff --git a/lib/dpctl.c b/lib/dpctl.c
> index a1ea25b..bd33ac4 100644
> --- a/lib/dpctl.c
> +++ b/lib/dpctl.c
> @@ -825,6 +825,10 @@ format_dpif_flow(struct ds *ds, const struct dpif_flow
> *f, struct hmap *ports,
> }
> ds_put_cstr(ds, ", actions:");
> format_odp_actions(ds, f->actions, f->actions_len, ports);
> +if (dpctl_p->verbosity && f->attrs.dp_extra_info) {
> +ds_put_format(ds, ", dp-extra-info:miniflow_bits%s",
> + f->attrs.dp_extra_info);
Please, make 'miniflow_bits' part of f->attrs.dp_extra_info.
This doesn't make sense for other datapaths.
And the string leaked here.
> +}
> }
>
> struct dump_types {
> diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
> index 079bd1b..51def10 100644
> --- a/lib/dpif-netdev.c
> +++ b/lib/dpif-netdev.c
> @@ -3101,6 +3101,14 @@ dp_netdev_flow_to_dpif_flow(const struct
> dp_netdev_flow *netdev_flow,
>
> flow->attrs.offloaded = false;
> flow->attrs.dp_layer = "ovs";
> +
> +struct ds extra_info = DS_EMPTY_INITIALIZER;
> +
> +ds_put_format(_info, "(0x%X,0x%X)",
> + count_1bits(netdev_flow->cr.mask->mf.map.bits[0]),
> + count_1bits(netdev_flow->cr.mask->mf.map.bits[1]));
> +flow->attrs.dp_extra_info = ds_steal_cstr(_info);
> +ds_destroy(_info);
> }
>
> static int
> diff --git a/lib/dpif.h b/lib/dpif.h
> index c21e897..064f884 100644
> --- a/lib/dpif.h
> +++ b/lib/dpif.h
> @@ -513,6 +513,7 @@ struct dpif_flow_detailed_stats {
> struct dpif_flow_attrs {
> bool offloaded; /* True if flow is offloaded to HW. */
> const char *dp_layer; /* DP layer the flow is handled in. */
> +char *dp_extra_info;
Comment required. Keep it generic, please, i.e. no mentioning of
'miniflow_bits'.
> };
>
> struct dpif_flow_dump_types {
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v5 2/2] netdev-dpdk: Add new DPDK RFC 4115 egress policer
On 15/01/2020 13:19, Stokes, Ian wrote: > > > On 1/15/2020 12:19 PM, Ilya Maximets wrote: >> On 15.01.2020 12:28, Stokes, Ian wrote: >>> >>> >>> On 1/14/2020 4:12 PM, Eelco Chaudron wrote: This patch adds a new policer to the DPDK datapath based on RFC 4115's Two-Rate, Three-Color marker. It's a two-level hierarchical policer which first does a color-blind marking of the traffic at the queue level, followed by a color-aware marking at the port level. At the end traffic marked as Green or Yellow is forwarded, Red is dropped. For details on how traffic is marked, see RFC 4115. This egress policer can be used to limit traffic at different rated based on the queues the traffic is in. In addition, it can also be used to prioritize certain traffic over others at a port level. For example, the following configuration will limit the traffic rate at a port level to a maximum of 2000 packets a second (64 bytes IPv4 packets). 100pps as CIR (Committed Information Rate) and 1000pps as EIR (Excess Information Rate). High priority traffic is routed to queue 10, which marks all traffic as CIR, i.e. Green. All low priority traffic, queue 20, is marked as EIR, i.e. Yellow. ovs-vsctl --timeout=5 set port dpdk1 qos=@myqos -- \ --id=@myqos create qos type=trtcm-policer \ other-config:cir=52000 other-config:cbs=2048 \ other-config:eir=52000 other-config:ebs=2048 \ queues:10=@dpdk1Q10 queues:20=@dpdk1Q20 -- \ --id=@dpdk1Q10 create queue \ other-config:cir=4160 other-config:cbs=2048 \ other-config:eir=0 other-config:ebs=0 -- \ --id=@dpdk1Q20 create queue \ other-config:cir=0 other-config:cbs=0 \ other-config:eir=4160 other-config:ebs=2048 \ This configuration accomplishes that the high priority traffic has a guaranteed bandwidth egressing the ports at CIR (1000pps), but it can also use the EIR, so a total of 2000pps at max. These additional 1000pps is shared with the low priority traffic. The low priority traffic can use at maximum 1000pps. >>> Thanks for the patch Eelco, minor comment below. >>> >>> >>> Rate Limiting (Ingress Policing) diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c index 128963f..1ed4a47 100644 --- a/lib/netdev-dpdk.c +++ b/lib/netdev-dpdk.c @@ -26,6 +26,12 @@ #include #include +/* Include rte_compat.h first to allow experimental API's needed for the + * rte_meter.h rfc4115 functions. Once they are no longer marked as + * experimental the #define and rte_compat.h include can be removed. + */ +#define ALLOW_EXPERIMENTAL_API +#include >>> >>> I guess the risk here, from what I understand, this approach is all or >>> nothing in terms of experimental APIs from the included headers, other >>> experimental APIs could be used from DPDK going forward without causing >>> warning? >>> >>> If so, there would have to be extra dilligence taken when reviewing future >>> patches and a discussion if an API is expereimental, should it wait until >>> it is marked as non experimental. (In this case The TRTCM looks stable and >>> is highly unlikey to be removed so it's not an issue IMO). >>> >>> @Ilya/Kevin: Would you agree with above? Thoughts? >> >> I think it make sense to wait for API to become non-experimental >> if we have no easy way to enable it only on functions we need. >> I agree that having widly enabled experimental api might produce >> additional issues and will require more careful review of all the >> DPDK related patches. > > So I'm ok with making an exception in this case for the feature, I think > it was an oversight but the API is stable. But what I'm hearing is in > general the rule should be for new features the API should not be > experimental and if it is then it would have to have it's experimental > tag removed by the next DPDK upgrade (in this case 20.11 for arguments > sake) and then can be upstreamed to OVS master. > In this case, it sounds ok to me. We know it will be non-experimental in the next hours/days and we will not be left with some zombie feature on upgrade. Plus, there might be an acceptable way of adding a non-experimental symbol for this to the v19.11 stable branch too (not guaranteed though), and if so we could turn this off on upgrade to v19.11.X. OTOH, I don't know how important it is to have this feature in OVS 2.13. >> >> BTW, another thought I have in mind about all the release management is: >> Shouldn't we hold OVS updates to new DPDK LTS until the first correction >> release is out? I mean, for example, Ubuntu triggers updates from one >> LTS release to another only after .1 correcting relese is out (users >> of Ubuntu 18.04 will receive upgrade notifications only after 20.04.1 >> is released). Shouldn't we do the same thing?
[ovs-dev] [PATCH net-next v3] openvswitch: add TTL decrement action
New action to decrement TTL instead of setting it to a fixed value.
This action will decrement the TTL and, in case of expired TTL, drop it
or execute an action passed via a nested attribute.
The default TTL expired action is to drop the packet.
Supports both IPv4 and IPv6 via the ttl and hop_limit fields, respectively.
Tested with a corresponding change in the userspace:
# ovs-dpctl dump-flows
in_port(2),eth(),eth_type(0x0800), packets:0, bytes:0, used:never,
actions:dec_ttl{ttl<=1 action:(drop)},1
in_port(1),eth(),eth_type(0x0800), packets:0, bytes:0, used:never,
actions:dec_ttl{ttl<=1 action:(drop)},2
in_port(1),eth(),eth_type(0x0806), packets:0, bytes:0, used:never, actions:2
in_port(2),eth(),eth_type(0x0806), packets:0, bytes:0, used:never, actions:1
# ping -c1 192.168.0.2 -t 42
IP (tos 0x0, ttl 41, id 61647, offset 0, flags [DF], proto ICMP (1), length
84)
192.168.0.1 > 192.168.0.2: ICMP echo request, id 386, seq 1, length 64
# ping -c1 192.168.0.2 -t 120
IP (tos 0x0, ttl 119, id 62070, offset 0, flags [DF], proto ICMP (1),
length 84)
192.168.0.1 > 192.168.0.2: ICMP echo request, id 388, seq 1, length 64
# ping -c1 192.168.0.2 -t 1
#
Co-developed-by: Bindiya Kurle
Signed-off-by: Bindiya Kurle
Signed-off-by: Matteo Croce
---
include/uapi/linux/openvswitch.h | 2 +
net/openvswitch/actions.c| 67 ++
net/openvswitch/flow_netlink.c | 71
3 files changed, 140 insertions(+)
diff --git a/include/uapi/linux/openvswitch.h b/include/uapi/linux/openvswitch.h
index ae2bff14e7e1..9d3f040847af 100644
--- a/include/uapi/linux/openvswitch.h
+++ b/include/uapi/linux/openvswitch.h
@@ -958,6 +958,7 @@ enum ovs_action_attr {
OVS_ACTION_ATTR_CLONE,/* Nested OVS_CLONE_ATTR_*. */
OVS_ACTION_ATTR_CHECK_PKT_LEN, /* Nested OVS_CHECK_PKT_LEN_ATTR_*. */
OVS_ACTION_ATTR_ADD_MPLS, /* struct ovs_action_add_mpls. */
+ OVS_ACTION_ATTR_DEC_TTL, /* Nested OVS_DEC_TTL_ATTR_*. */
__OVS_ACTION_ATTR_MAX,/* Nothing past this will be accepted
* from userspace. */
@@ -1050,4 +1051,5 @@ struct ovs_zone_limit {
__u32 count;
};
+#define OVS_DEC_TTL_ATTR_EXEC 0
#endif /* _LINUX_OPENVSWITCH_H */
diff --git a/net/openvswitch/actions.c b/net/openvswitch/actions.c
index 7fbfe2adfffa..1b0afc9bf1ad 100644
--- a/net/openvswitch/actions.c
+++ b/net/openvswitch/actions.c
@@ -964,6 +964,26 @@ static int output_userspace(struct datapath *dp, struct
sk_buff *skb,
return ovs_dp_upcall(dp, skb, key, , cutlen);
}
+static int dec_ttl(struct datapath *dp, struct sk_buff *skb,
+ struct sw_flow_key *key,
+ const struct nlattr *attr, bool last)
+{
+ /* The first action is always 'OVS_DEC_TTL_ATTR_ARG'. */
+ struct nlattr *dec_ttl_arg = nla_data(attr);
+ u32 nested = nla_get_u32(dec_ttl_arg);
+ int rem = nla_len(attr);
+
+ if (nested) {
+ struct nlattr *actions = nla_next(dec_ttl_arg, );
+
+ if (actions)
+ return clone_execute(dp, skb, key, 0, actions, rem,
+last, false);
+ }
+ consume_skb(skb);
+ return 0;
+}
+
/* When 'last' is true, sample() should always consume the 'skb'.
* Otherwise, sample() should keep 'skb' intact regardless what
* actions are executed within sample().
@@ -1180,6 +1200,45 @@ static int execute_check_pkt_len(struct datapath *dp,
struct sk_buff *skb,
nla_len(actions), last, clone_flow_key);
}
+static int execute_dec_ttl(struct sk_buff *skb, struct sw_flow_key *key)
+{
+ int err;
+
+ if (skb->protocol == htons(ETH_P_IPV6)) {
+ struct ipv6hdr *nh;
+
+ err = skb_ensure_writable(skb, skb_network_offset(skb) +
+ sizeof(*nh));
+ if (unlikely(err))
+ return err;
+
+ nh = ipv6_hdr(skb);
+
+ if (nh->hop_limit <= 1)
+ return -EHOSTUNREACH;
+
+ key->ip.ttl = --nh->hop_limit;
+ } else {
+ struct iphdr *nh;
+ u8 old_ttl;
+
+ err = skb_ensure_writable(skb, skb_network_offset(skb) +
+ sizeof(*nh));
+ if (unlikely(err))
+ return err;
+
+ nh = ip_hdr(skb);
+ if (nh->ttl <= 1)
+ return -EHOSTUNREACH;
+
+ old_ttl = nh->ttl--;
+ csum_replace2(>check, htons(old_ttl << 8),
+ htons(nh->ttl << 8));
+ key->ip.ttl = nh->ttl;
+ }
+ return 0;
+}
+
/* Execute a list of actions against 'skb'. */
static int do_execute_actions(struct datapath *dp, struct
[ovs-dev] [v3] dpif-netdev: Modified ovs-appctl dpctl/dump-flows command
Modified ovs-appctl dpctl/dump-flows command to output
the miniflow bits for a given flow when -m option is passed.
$ ovs-appctl dpctl/dump-flows -m
Signed-off-by: Emma Finn
---
RFC -> v1
* Changed revision from RFC to v1
* Reformatted based on comments
* Fixed same classifier being dumped multiple times
flagged by Ilya
* Fixed print of subtables flagged by William
* Updated print count of bits as well as bits themselves
---
v1 -> v2
* Reformatted based on comments
* Refactored code to make output part of ovs-appctl
dpctl/dump-flows -m command.
---
v2 -> v3
* Added attribute dp_extra_info to dpif_flow_attrs struct
to store miniflow bits as a string
---
NEWS | 2 ++
lib/dpctl.c | 4
lib/dpif-netdev.c | 8
lib/dpif.h| 1 +
4 files changed, 15 insertions(+)
diff --git a/NEWS b/NEWS
index 965faca..1c9d2db 100644
--- a/NEWS
+++ b/NEWS
@@ -8,6 +8,8 @@ Post-v2.12.0
* Add option to enable, disable and query TCP sequence checking in
conntrack.
* Add support for conntrack zone limits.
+ * Command "ovs-appctl dpctl/dump-flows" refactored to show subtable
+ miniflow bits for userspace datapath.
- AF_XDP:
* New option 'use-need-wakeup' for netdev-afxdp to control enabling
of corresponding 'need_wakeup' flag in AF_XDP rings. Enabled by default
diff --git a/lib/dpctl.c b/lib/dpctl.c
index a1ea25b..bd33ac4 100644
--- a/lib/dpctl.c
+++ b/lib/dpctl.c
@@ -825,6 +825,10 @@ format_dpif_flow(struct ds *ds, const struct dpif_flow *f,
struct hmap *ports,
}
ds_put_cstr(ds, ", actions:");
format_odp_actions(ds, f->actions, f->actions_len, ports);
+if (dpctl_p->verbosity && f->attrs.dp_extra_info) {
+ds_put_format(ds, ", dp-extra-info:miniflow_bits%s",
+ f->attrs.dp_extra_info);
+}
}
struct dump_types {
diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index 079bd1b..51def10 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@ -3101,6 +3101,14 @@ dp_netdev_flow_to_dpif_flow(const struct dp_netdev_flow
*netdev_flow,
flow->attrs.offloaded = false;
flow->attrs.dp_layer = "ovs";
+
+struct ds extra_info = DS_EMPTY_INITIALIZER;
+
+ds_put_format(_info, "(0x%X,0x%X)",
+ count_1bits(netdev_flow->cr.mask->mf.map.bits[0]),
+ count_1bits(netdev_flow->cr.mask->mf.map.bits[1]));
+flow->attrs.dp_extra_info = ds_steal_cstr(_info);
+ds_destroy(_info);
}
static int
diff --git a/lib/dpif.h b/lib/dpif.h
index c21e897..064f884 100644
--- a/lib/dpif.h
+++ b/lib/dpif.h
@@ -513,6 +513,7 @@ struct dpif_flow_detailed_stats {
struct dpif_flow_attrs {
bool offloaded; /* True if flow is offloaded to HW. */
const char *dp_layer; /* DP layer the flow is handled in. */
+char *dp_extra_info;
};
struct dpif_flow_dump_types {
--
2.7.4
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] ??12???????????
[[-Domain-]]
O60Y7D[[-User-]]
[[-Now-]]N0Ag09[12]g2AO20�01v84�AENF6�0C�D9f2Fu31N8E|FB~DF^F6�DF�20b10v84�0Ce74e39Y82N0B�1A
\06_85Y04t06�AENF6SD1^03R30e36NF6{B1002
g65n90�1A{A1t06T58e2Fc01
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v5 2/2] netdev-dpdk: Add new DPDK RFC 4115 egress policer
On 1/15/2020 12:19 PM, Ilya Maximets wrote: On 15.01.2020 12:28, Stokes, Ian wrote: On 1/14/2020 4:12 PM, Eelco Chaudron wrote: This patch adds a new policer to the DPDK datapath based on RFC 4115's Two-Rate, Three-Color marker. It's a two-level hierarchical policer which first does a color-blind marking of the traffic at the queue level, followed by a color-aware marking at the port level. At the end traffic marked as Green or Yellow is forwarded, Red is dropped. For details on how traffic is marked, see RFC 4115. This egress policer can be used to limit traffic at different rated based on the queues the traffic is in. In addition, it can also be used to prioritize certain traffic over others at a port level. For example, the following configuration will limit the traffic rate at a port level to a maximum of 2000 packets a second (64 bytes IPv4 packets). 100pps as CIR (Committed Information Rate) and 1000pps as EIR (Excess Information Rate). High priority traffic is routed to queue 10, which marks all traffic as CIR, i.e. Green. All low priority traffic, queue 20, is marked as EIR, i.e. Yellow. ovs-vsctl --timeout=5 set port dpdk1 qos=@myqos -- \ --id=@myqos create qos type=trtcm-policer \ other-config:cir=52000 other-config:cbs=2048 \ other-config:eir=52000 other-config:ebs=2048 \ queues:10=@dpdk1Q10 queues:20=@dpdk1Q20 -- \ --id=@dpdk1Q10 create queue \ other-config:cir=4160 other-config:cbs=2048 \ other-config:eir=0 other-config:ebs=0 -- \ --id=@dpdk1Q20 create queue \ other-config:cir=0 other-config:cbs=0 \ other-config:eir=4160 other-config:ebs=2048 \ This configuration accomplishes that the high priority traffic has a guaranteed bandwidth egressing the ports at CIR (1000pps), but it can also use the EIR, so a total of 2000pps at max. These additional 1000pps is shared with the low priority traffic. The low priority traffic can use at maximum 1000pps. Thanks for the patch Eelco, minor comment below. Rate Limiting (Ingress Policing) diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c index 128963f..1ed4a47 100644 --- a/lib/netdev-dpdk.c +++ b/lib/netdev-dpdk.c @@ -26,6 +26,12 @@ #include #include +/* Include rte_compat.h first to allow experimental API's needed for the + * rte_meter.h rfc4115 functions. Once they are no longer marked as + * experimental the #define and rte_compat.h include can be removed. + */ +#define ALLOW_EXPERIMENTAL_API +#include I guess the risk here, from what I understand, this approach is all or nothing in terms of experimental APIs from the included headers, other experimental APIs could be used from DPDK going forward without causing warning? If so, there would have to be extra dilligence taken when reviewing future patches and a discussion if an API is expereimental, should it wait until it is marked as non experimental. (In this case The TRTCM looks stable and is highly unlikey to be removed so it's not an issue IMO). @Ilya/Kevin: Would you agree with above? Thoughts? I think it make sense to wait for API to become non-experimental if we have no easy way to enable it only on functions we need. I agree that having widly enabled experimental api might produce additional issues and will require more careful review of all the DPDK related patches. So I'm ok with making an exception in this case for the feature, I think it was an oversight but the API is stable. But what I'm hearing is in general the rule should be for new features the API should not be experimental and if it is then it would have to have it's experimental tag removed by the next DPDK upgrade (in this case 20.11 for arguments sake) and then can be upstreamed to OVS master. BTW, another thought I have in mind about all the release management is: Shouldn't we hold OVS updates to new DPDK LTS until the first correction release is out? I mean, for example, Ubuntu triggers updates from one LTS release to another only after .1 correcting relese is out (users of Ubuntu 18.04 will receive upgrade notifications only after 20.04.1 is released). Shouldn't we do the same thing? Shouldn't we upgrade to the next DPDK LTS only after XX.11.1 is ready? This might make sense in order to not have obviously broken functionality in OVS releases but at the same time might just defer actual revealing of DPDK issues, so I'm not fully sure about this. Since OVS is not the only user of DPDK, this still might make sense anyway. Would like to hear some thoughts. Yes, I've thought about this as well. There certainly is advantage to moving to a .1 release in terms of stability instead of .0. However when I thought about the release two things came to mind. (i) By moving to the .0 release, is OVS in a position to better contribute feedback for the .1 release and ensure relevant patches for OVS with DPDK fixes are upstreamed in the .1 (rather than a .2). Feedback coming not from just the developers but also from
Re: [ovs-dev] [PATCH v5 2/2] netdev-dpdk: Add new DPDK RFC 4115 egress policer
On 15.01.2020 12:28, Stokes, Ian wrote: > > > On 1/14/2020 4:12 PM, Eelco Chaudron wrote: >> This patch adds a new policer to the DPDK datapath based on RFC 4115's >> Two-Rate, Three-Color marker. It's a two-level hierarchical policer >> which first does a color-blind marking of the traffic at the queue >> level, followed by a color-aware marking at the port level. At the end >> traffic marked as Green or Yellow is forwarded, Red is dropped. For >> details on how traffic is marked, see RFC 4115. >> >> This egress policer can be used to limit traffic at different rated >> based on the queues the traffic is in. In addition, it can also be used >> to prioritize certain traffic over others at a port level. >> >> For example, the following configuration will limit the traffic rate at a >> port level to a maximum of 2000 packets a second (64 bytes IPv4 packets). >> 100pps as CIR (Committed Information Rate) and 1000pps as EIR (Excess >> Information Rate). High priority traffic is routed to queue 10, which marks >> all traffic as CIR, i.e. Green. All low priority traffic, queue 20, is >> marked as EIR, i.e. Yellow. >> >> ovs-vsctl --timeout=5 set port dpdk1 qos=@myqos -- \ >> --id=@myqos create qos type=trtcm-policer \ >> other-config:cir=52000 other-config:cbs=2048 \ >> other-config:eir=52000 other-config:ebs=2048 \ >> queues:10=@dpdk1Q10 queues:20=@dpdk1Q20 -- \ >> --id=@dpdk1Q10 create queue \ >> other-config:cir=4160 other-config:cbs=2048 \ >> other-config:eir=0 other-config:ebs=0 -- \ >> --id=@dpdk1Q20 create queue \ >> other-config:cir=0 other-config:cbs=0 \ >> other-config:eir=4160 other-config:ebs=2048 \ >> >> This configuration accomplishes that the high priority traffic has a >> guaranteed bandwidth egressing the ports at CIR (1000pps), but it can also >> use the EIR, so a total of 2000pps at max. These additional 1000pps is >> shared with the low priority traffic. The low priority traffic can use at >> maximum 1000pps. >> > Thanks for the patch Eelco, minor comment below. > > > >> Rate Limiting (Ingress Policing) >> diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c >> index 128963f..1ed4a47 100644 >> --- a/lib/netdev-dpdk.c >> +++ b/lib/netdev-dpdk.c >> @@ -26,6 +26,12 @@ >> #include >> #include >> +/* Include rte_compat.h first to allow experimental API's needed for the >> + * rte_meter.h rfc4115 functions. Once they are no longer marked as >> + * experimental the #define and rte_compat.h include can be removed. >> + */ >> +#define ALLOW_EXPERIMENTAL_API >> +#include > > I guess the risk here, from what I understand, this approach is all or > nothing in terms of experimental APIs from the included headers, other > experimental APIs could be used from DPDK going forward without causing > warning? > > If so, there would have to be extra dilligence taken when reviewing future > patches and a discussion if an API is expereimental, should it wait until it > is marked as non experimental. (In this case The TRTCM looks stable and is > highly unlikey to be removed so it's not an issue IMO). > > @Ilya/Kevin: Would you agree with above? Thoughts? I think it make sense to wait for API to become non-experimental if we have no easy way to enable it only on functions we need. I agree that having widly enabled experimental api might produce additional issues and will require more careful review of all the DPDK related patches. BTW, another thought I have in mind about all the release management is: Shouldn't we hold OVS updates to new DPDK LTS until the first correction release is out? I mean, for example, Ubuntu triggers updates from one LTS release to another only after .1 correcting relese is out (users of Ubuntu 18.04 will receive upgrade notifications only after 20.04.1 is released). Shouldn't we do the same thing? Shouldn't we upgrade to the next DPDK LTS only after XX.11.1 is ready? This might make sense in order to not have obviously broken functionality in OVS releases but at the same time might just defer actual revealing of DPDK issues, so I'm not fully sure about this. Since OVS is not the only user of DPDK, this still might make sense anyway. Would like to hear some thoughts. Best regards, Ilya Maximets. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] REPLY
Dear, It is a great privileged that i am contacting you through this medium, My name is Barr.NICK YUN, I have an important business transaction that will be of great interest to you. If you are capable of receiving US$6.5Million, then you are the right choice. Kindly get back to me as soon as possible for more details. Barr.Nick Yun ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v5 1/2] netdev-dpdk: Add support for multi-queue QoS to the DPDK datapath
On 15 Jan 2020, at 12:20, Stokes, Ian wrote: On 1/14/2020 4:12 PM, Eelco Chaudron wrote: This patch adds support for multi-queue QoS to the DPDK datapath. Most of the code is based on an earlier patch from a patchset sent out by zhaozhanxu. The patch was titled "[ovs-dev, v2, 1/4] netdev-dpdk.c: Support the multi-queue QoS configuration for dpdk datapath" Co-authored-by: zhaozhanxu Signed-off-by: Eelco Chaudron Thansk Eelco. Overall LGTM, there should be a sign-off for zhaozhanxu also as he is a co-athour, I can add this on commit however. Thanks, please add the sign-off, as it was on his original patch set. I did try to contact him earlier, but never got a response. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH 2/3] ovn-controller.c: Move the position of handling OVN-SB related settings.
> On Jan 14, 2020, at 5:34 PM, Han Zhou wrote:
>
> On Tue, Jan 14, 2020 at 1:24 PM Mark Michelson wrote:
>>
>> The commit message doesn't make much sense to me. The external-ids are
>> set outside of ovn-controller, so the concept of them being handled in
>> "the same iteration" or "the next one" only works if ovn-controller is
>> setting them at some point in the loop.
>>
> Maybe the commit message is not clear enough. Let me explain with more
> details.
> In each iteration, the OVS IDL's data is updated AFTER the line:
>struct ovsdb_idl_txn *ovs_idl_txn = ovsdb_idl_loop_run(_idl_loop);
>
> Without this patch, it (the lines that are moved) applies the settings
> before reading the new settings. So if a change is made to external-ids,
> e.g. ovn-remote-db, the loop will be waked up because of the OVSDB RPC
> messages, but it won't apply any of the new settings. The new settings will
> be applied only if there is another event coming to wake the loop, e.g.
> probe interval timeout. In my testing I saw the change took effect after 5
> seconds when probe interval timed out. If probe was disabled, it would
> never got applied unless a new change is made. I suspect the problem
> reported here [0] may due to the same reason.
>
> [0]
> https://mail.openvswitch.org/pipermail/ovs-discuss/2020-January/049695.html
>
>> Couldn't this have a negative effect on the first iteration of the loop?
>> If we don't set SSL parameters or the sb remote first, then we will have
>> errors when attempting to connect to the southbound database.
>>
>
> At the first iteration, it just make sure the OVS IDL data is refreshed
> before setting the SSL parameters. We are still setting the parameters. The
> patch doesn't skip anything.
>
>> On 1/13/20 5:52 PM, Han Zhou wrote:
>>> Move the logic of handling OVN-SB related setting in external-ids
>>> after the ovs_idl_loop run, so that any change in the external-ids
>>> settings can take effect in the same iteration, without waiting for
>>> the next one.
>>>
>>> Signed-off-by: Han Zhou
>>> ---
>>> controller/ovn-controller.c | 8
>>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/controller/ovn-controller.c b/controller/ovn-controller.c
>>> index 3d843f7..abb1b4c 100644
>>> --- a/controller/ovn-controller.c
>>> +++ b/controller/ovn-controller.c
>>> @@ -2012,10 +2012,6 @@ main(int argc, char *argv[])
>>> while (!exiting) {
>>> engine_init_run();
>>>
>>> -update_sb_db(ovs_idl_loop.idl, ovnsb_idl_loop.idl);
>>> -update_ssl_config(ovsrec_ssl_table_get(ovs_idl_loop.idl));
>>> -
> ofctrl_set_probe_interval(get_ofctrl_probe_interval(ovs_idl_loop.idl));
>>> -
>>> struct ovsdb_idl_txn *ovs_idl_txn =
> ovsdb_idl_loop_run(_idl_loop);
>>> unsigned int new_ovs_cond_seqno
>>> = ovsdb_idl_get_condition_seqno(ovs_idl_loop.idl);
>>> @@ -2027,6 +2023,10 @@ main(int argc, char *argv[])
>>> ovs_cond_seqno = new_ovs_cond_seqno;
>>> }
>>>
>>> +update_sb_db(ovs_idl_loop.idl, ovnsb_idl_loop.idl);
>>> +update_ssl_config(ovsrec_ssl_table_get(ovs_idl_loop.idl));
>>> +
> ofctrl_set_probe_interval(get_ofctrl_probe_interval(ovs_idl_loop.idl));
>>> +
>>> struct ovsdb_idl_txn *ovnsb_idl_txn
>>> = ovsdb_idl_loop_run(_idl_loop);
>>> unsigned int new_ovnsb_cond_seqno
>>>
>>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
This change addresses the issue of setting the tunnel as Lars discovered.
I needs to be back merged to 2.12 as well.
Reported-at:
https://mail.openvswitch.org/pipermail/ovs-discuss/2020-January/049695.html
Tested-by: Flavio Fernandes
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v5 2/2] netdev-dpdk: Add new DPDK RFC 4115 egress policer
On 1/14/2020 4:12 PM, Eelco Chaudron wrote:
This patch adds a new policer to the DPDK datapath based on RFC 4115's
Two-Rate, Three-Color marker. It's a two-level hierarchical policer
which first does a color-blind marking of the traffic at the queue
level, followed by a color-aware marking at the port level. At the end
traffic marked as Green or Yellow is forwarded, Red is dropped. For
details on how traffic is marked, see RFC 4115.
This egress policer can be used to limit traffic at different rated
based on the queues the traffic is in. In addition, it can also be used
to prioritize certain traffic over others at a port level.
For example, the following configuration will limit the traffic rate at a
port level to a maximum of 2000 packets a second (64 bytes IPv4 packets).
100pps as CIR (Committed Information Rate) and 1000pps as EIR (Excess
Information Rate). High priority traffic is routed to queue 10, which marks
all traffic as CIR, i.e. Green. All low priority traffic, queue 20, is
marked as EIR, i.e. Yellow.
ovs-vsctl --timeout=5 set port dpdk1 qos=@myqos -- \
--id=@myqos create qos type=trtcm-policer \
other-config:cir=52000 other-config:cbs=2048 \
other-config:eir=52000 other-config:ebs=2048 \
queues:10=@dpdk1Q10 queues:20=@dpdk1Q20 -- \
--id=@dpdk1Q10 create queue \
other-config:cir=4160 other-config:cbs=2048 \
other-config:eir=0 other-config:ebs=0 -- \
--id=@dpdk1Q20 create queue \
other-config:cir=0 other-config:cbs=0 \
other-config:eir=4160 other-config:ebs=2048 \
This configuration accomplishes that the high priority traffic has a
guaranteed bandwidth egressing the ports at CIR (1000pps), but it can also
use the EIR, so a total of 2000pps at max. These additional 1000pps is
shared with the low priority traffic. The low priority traffic can use at
maximum 1000pps.
Thanks for the patch Eelco, minor comment below.
Rate Limiting (Ingress Policing)
diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
index 128963f..1ed4a47 100644
--- a/lib/netdev-dpdk.c
+++ b/lib/netdev-dpdk.c
@@ -26,6 +26,12 @@
#include
#include
+/* Include rte_compat.h first to allow experimental API's needed for the
+ * rte_meter.h rfc4115 functions. Once they are no longer marked as
+ * experimental the #define and rte_compat.h include can be removed.
+ */
+#define ALLOW_EXPERIMENTAL_API
+#include
I guess the risk here, from what I understand, this approach is all or
nothing in terms of experimental APIs from the included headers, other
experimental APIs could be used from DPDK going forward without causing
warning?
If so, there would have to be extra dilligence taken when reviewing
future patches and a discussion if an API is expereimental, should it
wait until it is marked as non experimental. (In this case The TRTCM
looks stable and is highly unlikey to be removed so it's not an issue IMO).
@Ilya/Kevin: Would you agree with above? Thoughts?
Ian
#include
#include
#include
@@ -329,8 +335,9 @@ struct dpdk_qos_ops {
struct netdev_dpdk_queue_state *state);
};
-/* dpdk_qos_ops for each type of user space QoS implementation */
+/* dpdk_qos_ops for each type of user space QoS implementation. */
static const struct dpdk_qos_ops egress_policer_ops;
+static const struct dpdk_qos_ops trtcm_policer_ops;
/*
* Array of dpdk_qos_ops, contains pointer to all supported QoS
@@ -338,6 +345,7 @@ static const struct dpdk_qos_ops egress_policer_ops;
*/
static const struct dpdk_qos_ops *const qos_confs[] = {
_policer_ops,
+_policer_ops,
NULL
};
@@ -2162,9 +2170,9 @@ netdev_dpdk_eth_tx_burst(struct netdev_dpdk *dev, int qid,
}
static inline bool
-netdev_dpdk_policer_pkt_handle(struct rte_meter_srtcm *meter,
- struct rte_meter_srtcm_profile *profile,
- struct rte_mbuf *pkt, uint64_t time)
+netdev_dpdk_srtcm_policer_pkt_handle(struct rte_meter_srtcm *meter,
+ struct rte_meter_srtcm_profile *profile,
+ struct rte_mbuf *pkt, uint64_t time)
{
uint32_t pkt_len = rte_pktmbuf_pkt_len(pkt) - sizeof(struct
rte_ether_hdr);
@@ -2173,10 +2181,10 @@ netdev_dpdk_policer_pkt_handle(struct rte_meter_srtcm *meter,
}
static int
-netdev_dpdk_policer_run(struct rte_meter_srtcm *meter,
-struct rte_meter_srtcm_profile *profile,
-struct rte_mbuf **pkts, int pkt_cnt,
-bool should_steal)
+srtcm_policer_run_single_packet(struct rte_meter_srtcm *meter,
+struct rte_meter_srtcm_profile *profile,
+struct rte_mbuf **pkts, int pkt_cnt,
+bool should_steal)
{
int i = 0;
int cnt = 0;
@@ -2186,8 +2194,8 @@ netdev_dpdk_policer_run(struct rte_meter_srtcm *meter,
for
[ovs-dev] LOOKING FOR GOOD PARTNER
Good Day Sir/Madam, With due respect, trust and humility, I write you the proposal which I believe, would be of great interest to you. I must first apologize for this unsolicited mail to you. I am aware that this is certainly an unconventional approach to establishing a relationship, but you will realize the need for my letter to you. You may be surprised to receive this letter from me since you don't know me in person. First I must introduce myself to you. I am ESSA MARK am from sierra loan based in UNITED KINGDOM. Right now am in Johannesburg South Africa for Investment proposal. For now i am looking for rightful person who is honest, that can help me in investing the little money my Late Father Deposited in a security company in United Kingdom but the taxes over there is much, a friend of my father advised me to come down to South Africa . The money he deposited in the private company was $5, 500,000,000 (FIVE MILLION FIVE HUNDRED THOUSAND UNITED STATE DOLLARS) I decided to reach you through your email address for help. As a Refugee (ASYLUM SEEKER) in South Africa, I am not allow to operate any bank account or to be involved in any huge financial transaction and as the only son of my father i am saddled with the responsibility of seeking a genuine foreign partner where this money could be transfer without any problem. If you therefore accept to assist me, please contact me, through my private (essamark2...@gmail.com) for more briefing on this business assistance/investment for your assistance i have two options for you, first, you can choose to have a certain percentage of the money, secondly you can go into partnership with me, proper profitable investment of the money in your country whichever the option you choose feel free to notify me. I f you do not prefer a partnership, I am willing to give you 20% of the total sum while the remaining 80% will be for my family investment in your country that will be under your care. I therefore implore you to please maintain the absolute confidentiality of the matter even if you decide not to help. Sincerely yours Essa Mark ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v5 1/2] netdev-dpdk: Add support for multi-queue QoS to the DPDK datapath
On 1/14/2020 4:12 PM, Eelco Chaudron wrote:
This patch adds support for multi-queue QoS to the DPDK datapath. Most of
the code is based on an earlier patch from a patchset sent out by
zhaozhanxu. The patch was titled "[ovs-dev, v2, 1/4] netdev-dpdk.c: Support
the multi-queue QoS configuration for dpdk datapath"
Co-authored-by: zhaozhanxu
Signed-off-by: Eelco Chaudron
Thansk Eelco.
Overall LGTM, there should be a sign-off for zhaozhanxu also as he is a
co-athour, I can add this on commit however.
Regards
Ian
---
lib/netdev-dpdk.c | 219 -
1 file changed, 213 insertions(+), 6 deletions(-)
diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
index 8198a0b..128963f 100644
--- a/lib/netdev-dpdk.c
+++ b/lib/netdev-dpdk.c
@@ -219,6 +219,13 @@ struct qos_conf {
rte_spinlock_t lock;
};
+/* QoS queue information used by the netdev queue dump functions. */
+struct netdev_dpdk_queue_state {
+uint32_t *queues;
+size_t cur_queue;
+size_t n_queues;
+};
+
/* A particular implementation of dpdk QoS operations.
*
* The functions below return 0 if successful or a positive errno value on
@@ -285,6 +292,41 @@ struct dpdk_qos_ops {
*/
int (*qos_run)(struct qos_conf *qos_conf, struct rte_mbuf **pkts,
int pkt_cnt, bool should_steal);
+
+/* Called to construct a QoS Queue. The implementation should make
+ * the appropriate calls to configure QoS Queue according to 'details'.
+ *
+ * The contents of 'details' should be documented as valid for 'ovs_name'
+ * in the "other_config" column in the "QoS" table in vswitchd/vswitch.xml
+ * (which is built as ovs-vswitchd.conf.db(8)).
+ *
+ * This function must return 0 if and only if it constructs
+ * QoS queue successfully.
+ */
+int (*qos_queue_construct)(const struct smap *details,
+ uint32_t queue_id, struct qos_conf *conf);
+
+/* Destroys the QoS Queue. */
+void (*qos_queue_destruct)(struct qos_conf *conf, uint32_t queue_id);
+
+/* Retrieves details of QoS Queue configuration into 'details'.
+ *
+ * The contents of 'details' should be documented as valid for 'ovs_name'
+ * in the "other_config" column in the "QoS" table in vswitchd/vswitch.xml
+ * (which is built as ovs-vswitchd.conf.db(8)).
+ */
+int (*qos_queue_get)(struct smap *details, uint32_t queue_id,
+ const struct qos_conf *conf);
+
+/* Retrieves statistics of QoS Queue configuration into 'stats'. */
+int (*qos_queue_get_stats)(const struct qos_conf *conf, uint32_t queue_id,
+ struct netdev_queue_stats *stats);
+
+/* Setup the 'netdev_dpdk_queue_state' structure used by the dpdk queue
+ * dump functions.
+ */
+int (*qos_queue_dump_state_init)(const struct qos_conf *conf,
+ struct netdev_dpdk_queue_state *state);
};
/* dpdk_qos_ops for each type of user space QoS implementation */
@@ -4191,6 +4233,164 @@ netdev_dpdk_set_qos(struct netdev *netdev, const char
*type,
return error;
}
+static int
+netdev_dpdk_get_queue(const struct netdev *netdev, uint32_t queue_id,
+ struct smap *details)
+{
+struct netdev_dpdk *dev = netdev_dpdk_cast(netdev);
+struct qos_conf *qos_conf;
+int error = 0;
+
+ovs_mutex_lock(>mutex);
+
+qos_conf = ovsrcu_get_protected(struct qos_conf *, >qos_conf);
+if (!qos_conf || !qos_conf->ops || !qos_conf->ops->qos_queue_get) {
+error = EOPNOTSUPP;
+} else {
+error = qos_conf->ops->qos_queue_get(details, queue_id, qos_conf);
+}
+
+ovs_mutex_unlock(>mutex);
+
+return error;
+}
+
+static int
+netdev_dpdk_set_queue(struct netdev *netdev, uint32_t queue_id,
+ const struct smap *details)
+{
+struct netdev_dpdk *dev = netdev_dpdk_cast(netdev);
+struct qos_conf *qos_conf;
+int error = 0;
+
+ovs_mutex_lock(>mutex);
+
+qos_conf = ovsrcu_get_protected(struct qos_conf *, >qos_conf);
+if (!qos_conf || !qos_conf->ops || !qos_conf->ops->qos_queue_construct) {
+error = EOPNOTSUPP;
+} else {
+error = qos_conf->ops->qos_queue_construct(details, queue_id,
+ qos_conf);
+}
+
+if (error && error != EOPNOTSUPP) {
+VLOG_ERR("Failed to set QoS queue %d on port %s: %s",
+ queue_id, netdev_get_name(netdev), rte_strerror(error));
+}
+
+ovs_mutex_unlock(>mutex);
+
+return error;
+}
+
+static int
+netdev_dpdk_delete_queue(struct netdev *netdev, uint32_t queue_id)
+{
+struct netdev_dpdk *dev = netdev_dpdk_cast(netdev);
+struct qos_conf *qos_conf;
+int error = 0;
+
+ovs_mutex_lock(>mutex);
+
+qos_conf = ovsrcu_get_protected(struct qos_conf *, >qos_conf);
+if (qos_conf && qos_conf->ops &&
[ovs-dev] ??12???????????
[[-Domain-]]
O60Y7D[[-User-]]
[[-Now-]]N0Ag09[12]g2AO20�01v84�AENF6�0C�D9f2Fu31N8E|FB~DF^F6�DF�20b10v84�0Ce74e39Y82N0B�1A
\06_85Y04t06�AENF6SD1^03R30e36NF6{B1002
g65n90�1A{A1t06T58e2Fc01
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
