[ovs-dev] Find tradeshows and conferences near you

[Eva from 10times via dev]

Hi there!
 
 Find your next opportunity at an event of your interest
 
 
 
 
 
 10times is the world's largest business event platform to find events,
business conferences, trade shows, global seminars, networking meets and
workshops.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Events near me
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Connect with 40m+ event goers world wide.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 300k business events from around the globe.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Professionals from more than 100 industries.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Network with event-goers from more than 200 countries & 8000 cities.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 For any queries, reach out to Helpdesk
 
 
 
 
 
 
 Download our official Apps
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 | Manage Email Subscription

Unsubscribe From This List 
http://links.10times.com/asm/unsubscribe/?user_id=1002061&data=YtGlTfwNSVH0zjLHoT2FEf8RUbJBuS7sJYxf6umntWXf1pJgrKwowJLFpNOteCTgXmh4umrYxX4QRE5Qr5v8RTClPCkZtVHFJB4VkxhEdmwyMaw_bx2ShuGSMpv1UO__FUsUKrExPsBBzju1EEo8dPgQKUpjXYuiAUWDp6wM8OUF1WATTkCzCCLilVTYVAdUUtLj-lKwBdFESTTahXY-zHFAIlxh06i0zNYPzvrSFEApx389_GtG31YXYT1-G2AbN9IP18Et-GtiG2IKWis7aKKHXeP1SU5w1SF8LfNF-_xx4DfnaAQAeaaUv0ywV4vBFgxy1qvECAs_rncRdTrSgRMq_AjC9k1HfXfepLC7RH5OjvoOsJ4DQbc-drhnVbIonxk4-yPPAZBLrDD7TtTI5TRVUoiP-qaMO2WgIeNl65_p8px-NalX3nsT0WYulPfw4mDZ2dy3_pg6Q0CStp8TYA9FXS04TyqaG-58hlVZEbBiXvSXgOy0r9qu6rzjf-3u
 | Manage Email Preferences 
http://links.10times.com/asm/?user_id=1002061&data=K32H7d_KaHLz5sOch6VVXuj6dWupAD_-RF9MHoEC0DORTmlJ24T84zChXd8Fz6fJdwQ1P1mSYDtpalHIuR5OF3ZcRVhxUSuuOVyF0sbbAZrVgu8WJyTKLoRXMuuampv-NctpAatwNNfbfBSauO9E73QiVT2ds_6Xae5Q-TVWgja4E1aBJ2cifWlKAJ2GVgKRh_wRrccMWc3XYKTVA6gGh_CQ97GKpyKUdDYMtFpYIAqT4TfeHdq7EFPLNUg98NLHznqF_Mk0KORIq0zvcjFfY5XVZNu8WN-eVjk8k_mIxxozL9FsTYEKtvu3TloJ6
 
TkZa2HQ_tDme2Xkv2RQJssuPPlGB7LmjQlttcvWSD6mdX_sXe_mx-wk7FVyBauN27ehVMaI-k2-Jso36nF1Zmy3Gc2OzA0QanriBOPY9fD8OrPzhLXhrWpC5gmJ_6Q2I4pMxNlAWLBvAqv0SJrSX2VZ_5oFr0BRXj3JZ2ElR6ok5go=
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] ofproto-dpif: Fix using uninitialized execute hash.

[Tonghao Zhang]

On Sat, Jan 4, 2020 at 7:50 AM Ilya Maximets  wrote:
>
> Most of callers doesn't initialize dpif_execute.hash leaving random
> value from the stack.  And this random value used later while encoding
> netlink message and might produce unwanted kernel behavior.
>
> Fix that by fully initializing dpif_execute structure.  Using
> designated initializers to avoid such issues in the future.
>
> Fixes: 0442bfb11d6c ("ofproto-dpif-upcall: Echo HASH attribute back to 
> datapath.")
Hi, this patch is a bugfix for commit id 0442bfb11d6c? I think it
improves the codes.
> Signed-off-by: Ilya Maximets 
> ---
>  ofproto/ofproto-dpif.c | 113 ++---
>  1 file changed, 50 insertions(+), 63 deletions(-)
>
> diff --git a/ofproto/ofproto-dpif.c b/ofproto/ofproto-dpif.c
> index b17c6cdca..d298e17cf 100644
> --- a/ofproto/ofproto-dpif.c
> +++ b/ofproto/ofproto-dpif.c
> @@ -1073,7 +1073,6 @@ check_masked_set_action(struct dpif_backer *backer)
>  {
>  struct eth_header *eth;
>  struct ofpbuf actions;
> -struct dpif_execute execute;
>  struct dp_packet packet;
>  struct flow flow;
>  int error;
> @@ -1098,14 +1097,13 @@ check_masked_set_action(struct dpif_backer *backer)
>
>  /* Execute the actions.  On older datapaths this fails with EINVAL, on
>   * newer datapaths it succeeds. */
> -execute.actions = actions.data;
> -execute.actions_len = actions.size;
> -execute.packet = &packet;
> -execute.flow = &flow;
> -execute.needs_help = false;
> -execute.probe = true;
> -execute.mtu = 0;
> -
> +struct dpif_execute execute = {
> +.actions = actions.data,
> +.actions_len = actions.size,
> +.packet = &packet,
> +.flow = &flow,
> +.probe = true,
> +};
>  error = dpif_execute(backer->dpif, &execute);
>
>  dp_packet_uninit(&packet);
> @@ -1127,7 +1125,6 @@ check_trunc_action(struct dpif_backer *backer)
>  {
>  struct eth_header *eth;
>  struct ofpbuf actions;
> -struct dpif_execute execute;
>  struct dp_packet packet;
>  struct ovs_action_trunc *trunc;
>  struct flow flow;
> @@ -1152,14 +1149,13 @@ check_trunc_action(struct dpif_backer *backer)
>
>  /* Execute the actions.  On older datapaths this fails with EINVAL, on
>   * newer datapaths it succeeds. */
> -execute.actions = actions.data;
> -execute.actions_len = actions.size;
> -execute.packet = &packet;
> -execute.flow = &flow;
> -execute.needs_help = false;
> -execute.probe = true;
> -execute.mtu = 0;
> -
> +struct dpif_execute execute = {
> +.actions = actions.data,
> +.actions_len = actions.size,
> +.packet = &packet,
> +.flow = &flow,
> +.probe = true,
> +};
>  error = dpif_execute(backer->dpif, &execute);
>
>  dp_packet_uninit(&packet);
> @@ -1181,7 +1177,6 @@ check_trunc_action(struct dpif_backer *backer)
>  static bool
>  check_clone(struct dpif_backer *backer)
>  {
> -struct dpif_execute execute;
>  struct eth_header *eth;
>  struct flow flow;
>  struct dp_packet packet;
> @@ -1204,14 +1199,13 @@ check_clone(struct dpif_backer *backer)
>
>  /* Execute the actions.  On older datapaths this fails with EINVAL, on
>   * newer datapaths it succeeds. */
> -execute.actions = actions.data;
> -execute.actions_len = actions.size;
> -execute.packet = &packet;
> -execute.flow = &flow;
> -execute.needs_help = false;
> -execute.probe = true;
> -execute.mtu = 0;
> -
> +struct dpif_execute execute = {
> +.actions = actions.data,
> +.actions_len = actions.size,
> +.packet = &packet,
> +.flow = &flow,
> +.probe = true,
> +};
>  error = dpif_execute(backer->dpif, &execute);
>
>  dp_packet_uninit(&packet);
> @@ -1233,7 +1227,6 @@ check_clone(struct dpif_backer *backer)
>  static bool
>  check_ct_eventmask(struct dpif_backer *backer)
>  {
> -struct dpif_execute execute;
>  struct dp_packet packet;
>  struct ofpbuf actions;
>  struct flow flow = {
> @@ -1266,14 +1259,13 @@ check_ct_eventmask(struct dpif_backer *backer)
>
>  /* Execute the actions.  On older datapaths this fails with EINVAL, on
>   * newer datapaths it succeeds. */
> -execute.actions = actions.data;
> -execute.actions_len = actions.size;
> -execute.packet = &packet;
> -execute.flow = &flow;
> -execute.needs_help = false;
> -execute.probe = true;
> -execute.mtu = 0;
> -
> +struct dpif_execute execute = {
> +.actions = actions.data,
> +.actions_len = actions.size,
> +.packet = &packet,
> +.flow = &flow,
> +.probe = true,
> +};
>  error = dpif_execute(backer->dpif, &execute);
>
>  dp_packet_uninit(&packet);
> @@ -1328,7 +1320,6 @@ check_ct_clear(struct dpif_backer *backer)
>  static bool
>  check_ct_timeout_policy(struct dpif_backer *backer)
>  {
> -struct dpif_

Re: [ovs-dev] [PATCH] ofproto-dpif-upcall: Fix using uninitialized upcall hash.

[Tonghao Zhang]

On Sat, Jan 4, 2020 at 8:16 AM Ilya Maximets  wrote:
>
> upcalls are allocated on stack and 'hash' field must be initialized
> regardless of attribute existence because it will be used later.
>
>  Conditional jump or move depends on uninitialised value(s)
> at 0xFA74A7: dpif_netlink_encode_execute (dpif-netlink.c:1828)
> by 0xFA6DE8: dpif_netlink_operate__ (dpif-netlink.c:1906)
> by 0xFA612F: dpif_netlink_operate_chunks (dpif-netlink.c:2219)
> by 0xFA0E36: dpif_netlink_operate (dpif-netlink.c:2275)
> by 0xE5AFAC: dpif_operate (dpif.c:1376)
> by 0xDF3922: handle_upcalls (ofproto-dpif-upcall.c:1615)
> by 0xDF269B: recv_upcalls (ofproto-dpif-upcall.c:857)
> by 0xDF1C49: udpif_upcall_handler (ofproto-dpif-upcall.c:759)
> by 0xF3A3FE: ovsthread_wrapper (ovs-thread.c:383)
> by 0x565F6DA: start_thread (pthread_create.c:463)
> by 0x615988E: clone (clone.S:95)
>   Uninitialised value was created by a stack allocation
> at 0xDF2258: recv_upcalls (ofproto-dpif-upcall.c:773)
>
> Fixes: 0442bfb11d6c ("ofproto-dpif-upcall: Echo HASH attribute back to 
> datapath.")
> Signed-off-by: Ilya Maximets 
> ---
>  ofproto/ofproto-dpif-upcall.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/ofproto/ofproto-dpif-upcall.c b/ofproto/ofproto-dpif-upcall.c
> index aac0554af..409286ab1 100644
> --- a/ofproto/ofproto-dpif-upcall.c
> +++ b/ofproto/ofproto-dpif-upcall.c
> @@ -786,6 +786,7 @@ recv_upcalls(struct handler *handler)
>  struct upcall *upcall = &upcalls[n_upcalls];
>  struct flow *flow = &flows[n_upcalls];
>  unsigned int mru = 0;
> +uint64_t hash = 0;
>  int error;
>
>  ofpbuf_use_stub(recv_buf, recv_stubs[n_upcalls],
> @@ -806,7 +807,7 @@ recv_upcalls(struct handler *handler)
>  }
>
>  if (dupcall->hash) {
> -upcall->hash = nl_attr_get_u64(dupcall->hash);
> +hash = nl_attr_get_u64(dupcall->hash);
>  }
>
>  error = upcall_receive(upcall, udpif->backer, &dupcall->packet,
> @@ -830,6 +831,7 @@ recv_upcalls(struct handler *handler)
>  upcall->key = dupcall->key;
>  upcall->key_len = dupcall->key_len;
>  upcall->ufid = &dupcall->ufid;
> +upcall->hash = hash;
>
>  upcall->out_tun_key = dupcall->out_tun_key;
>  upcall->actions = dupcall->actions;
> --
> 2.17.1
>
Acked-by: Tonghao Zhang 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v9 1/2] netdev-linux: Detect numa node id.

[0-day Robot]

Bleep bloop.  Greetings Yi-Hung Wei, I am a robot and I have tried out your 
patch.
Thanks for your contribution.

I encountered some error that I wasn't expecting.  See the details below.


checkpatch:
WARNING: Line lacks whitespace around operator
#134 FILE: lib/netdev-linux.c:1419:
numa_node_path = xasprintf("/sys/class/net/%s/device/numa_node", name);

Lines checked: 184, Warnings: 1, Errors: 0


Please check this out.  If you feel there has been an error, please email 
acon...@redhat.com

Thanks,
0-day Robot
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] From: William Johnson.

[William Johnson]

Hello,

Thank you for lending me your timeand as you may wish to know,I am the accounts 
updating officer with a leading bank
 here in London United Kingdom and the transaction is about an abandoned fund 
with us here hence I have perfected 
every arrangement to pull the funds totalling the sum of 29.9M British Pound 
Sterling into your account and it will take
 10 official working days for the funds to reflect in the account you will 
provide for the transfer as all the arrangements has
 been completed for a successful remittance into your account from the day I 
receive your reply with your details as stated
 below.

The payment has been in our records for a very long time as abandoned and on 
further investigations as the 
accounts officer,I discovered that the customer did not write any name as his 
next of kin during the account
 opening and on further inquiry,I was made to understand that the customer died 
on 17 March 2008 and the
 account has not been serviced since then  hence the rules is that after a 
period of 10yrs any abandoned funds 
should be taken to Her Majesty's Treasury Department and it will be ten years 
this fund has been abandoned
 this November hence I want to move the funds out to your account before the 
end of September 2019 before 
the management will discover that the customer is dead and that the account has 
been inoperative for 10 years
 hence you should forward the following asap:

1. Your full name and address
2. Your telephone numbers including your mobile number
3. Your bank name and address,swift/iban number,and your account number.
4. Your International passport/Driver's license for identification.

I will prepare an indemnity form on your name as the next of kin to the late 
account owner which the approval 
will begin from my department as the accounts updating officer and with the 
above details the funds will be released 
into your account within 10 working days as I expect your response with above 
request to proceed thank you.

Sincerely,

William Johnson.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH v9 2/2] netdev-afxdp: NUMA-aware memory allocation for XSK related memory

[Yi-Hung Wei]

Currently, the AF_XDP socket (XSK) related memory are allocated by main
thread in the main thread's NUMA domain.  With the patch that detects
netdev-linux's NUMA node id, the PMD thread of AF_XDP port will be run on
the AF_XDP netdev's NUMA domain.  If the net device's NUMA domain
is different from the main thread's NUMA domain, we will have two
cross-NUMA memory accesses (netdev <-> memory, memory <-> CPU).

This patch addresses the aforementioned issue by allocating
the memory in the net device's NUMA domain.

Signed-off-by: Yi-Hung Wei 
---
v9:
  - Addreess review comments from Ilya in patch 2.
* Add check on numa_available()
* Properly restore memory policy with get/set_mempolicy.

v8:
  - Addreess review comments from Eelco and Ilya in patch 2.
* Use OVS_FIND_DEPENDENCY().
* Avoid the locking issue when calling netdev_get_numa_id().
* Check NETDEV_NUMA_UNSPEC.
* Use return value from netdev_get_numa_id() directly, and
  check NETDEV_NUMA_UNSPEC case.
* Use numa_set_preferred().

---
 Documentation/intro/install/afxdp.rst |  2 +-
 acinclude.m4  |  2 ++
 include/sparse/automake.mk|  1 +
 include/sparse/numa.h | 27 +++
 lib/netdev-afxdp.c| 26 ++
 5 files changed, 57 insertions(+), 1 deletion(-)
 create mode 100644 include/sparse/numa.h

diff --git a/Documentation/intro/install/afxdp.rst 
b/Documentation/intro/install/afxdp.rst
index 7b0736c96114..c4685fa7ebac 100644
--- a/Documentation/intro/install/afxdp.rst
+++ b/Documentation/intro/install/afxdp.rst
@@ -164,7 +164,7 @@ If a test case fails, check the log at::
 
 Setup AF_XDP netdev
 ---
-Before running OVS with AF_XDP, make sure the libbpf and libelf are
+Before running OVS with AF_XDP, make sure the libbpf, libelf, and libnuma are
 set-up right::
 
   ldd vswitchd/ovs-vswitchd
diff --git a/acinclude.m4 b/acinclude.m4
index 542637ac8cb8..f73dc9bf7e3c 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -286,6 +286,8 @@ AC_DEFUN([OVS_CHECK_LINUX_AF_XDP], [
 AC_CHECK_FUNCS([pthread_spin_lock], [],
   [AC_MSG_ERROR([unable to find pthread_spin_lock for AF_XDP support])])
 
+OVS_FIND_DEPENDENCY([numa_alloc_onnode], [numa], [libnuma])
+
 AC_DEFINE([HAVE_AF_XDP], [1],
   [Define to 1 if AF_XDP support is available and enabled.])
 LIBBPF_LDADD=" -lbpf -lelf"
diff --git a/include/sparse/automake.mk b/include/sparse/automake.mk
index 073631e8c082..974ad3fe55f7 100644
--- a/include/sparse/automake.mk
+++ b/include/sparse/automake.mk
@@ -5,6 +5,7 @@ noinst_HEADERS += \
 include/sparse/bits/floatn.h \
 include/sparse/assert.h \
 include/sparse/math.h \
+include/sparse/numa.h \
 include/sparse/netinet/in.h \
 include/sparse/netinet/ip6.h \
 include/sparse/netpacket/packet.h \
diff --git a/include/sparse/numa.h b/include/sparse/numa.h
new file mode 100644
index ..3691a0eaf729
--- /dev/null
+++ b/include/sparse/numa.h
@@ -0,0 +1,27 @@
+/*
+ * Copyright (c) 2019 Nicira, Inc.
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at:
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+#ifndef __CHECKER__
+#error "Use this header only with sparse.  It is not a correct implementation."
+#endif
+
+/* Avoid sparse warning: non-ANSI function declaration of function" */
+#define numa_get_membind_compat() numa_get_membind_compat(void)
+#define numa_get_interleave_mask_compat() numa_get_interleave_mask_compat(void)
+#define numa_get_run_node_mask_compat() numa_get_run_node_mask_compat(void)
+
+/* Get actual  definitions for us to annotate and build on. */
+#include_next
diff --git a/lib/netdev-afxdp.c b/lib/netdev-afxdp.c
index 426dce944977..fad0aab9d550 100644
--- a/lib/netdev-afxdp.c
+++ b/lib/netdev-afxdp.c
@@ -26,6 +26,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -669,6 +671,24 @@ netdev_afxdp_reconfigure(struct netdev *netdev)
 struct rlimit r = {RLIM_INFINITY, RLIM_INFINITY};
 int err = 0;
 
+/* Allocate all the xsk related memory in the netdev's NUMA domain. */
+struct bitmask *old_bm = NULL;
+int old_policy, numa_id;
+if (numa_available() != -1) {
+numa_id = netdev_get_numa_id(netdev);
+if (numa_id != NETDEV_NUMA_UNSPEC) {
+old_bm = numa_allocate_nodemask();
+if (get_mempolicy(&old_policy, old_bm->maskp, old_bm->size + 1,
+   

[ovs-dev] [PATCH v9 1/2] netdev-linux: Detect numa node id.

[Yi-Hung Wei]

From: William Tu 

The patch detects the numa node id from the name of the netdev,
by reading the '/sys/class/net//device/numa_node'.
If not available, ex: virtual device, or any error happens,
return numa id 0.  Currently only the afxdp netdev type uses it,
other linux netdev types are disabled due to no use case.

Signed-off-by: William Tu 
Acked-by: Eelco Chaudron 
---
v9:
  - Addreess review comments from Ilya in patch 2.
* Add check on numa_available()
* Properly restore memory policy with get/set_mempolicy.
* Travis CI: https://travis-ci.org/YiHungWei/ovs/builds/632486578
v8:
  - Addreess review comments from Eelco and Ilya in patch 2.
* Use OVS_FIND_DEPENDENCY().
* Avoid the locking issue when calling netdev_get_numa_id().
* Check NETDEV_NUMA_UNSPEC.
* Use return value from netdev_get_numa_id() directly, and
  check NETDEV_NUMA_UNSPEC case.
* Use numa_set_preferred().
  - Travis CI: https://travis-ci.org/YiHungWei/ovs/builds/626865328

v7:
  - Add numa aware memory allocation for afxdp related memory in the following
patch.
  - Travis CI: https://travis-ci.org/YiHungWei/ovs/builds/626403984

v6:
  Feedbacks from Ilya
  - add thread safety check at netdev_linux_get_numa_id__, and
pass netdev_linux
  - preserve numa cache on netlink updates
  - Tested-at: https://travis-ci.org/williamtu/ovs-travis/builds/605634673

v5:
  Feedbacks from Ilya
  - reafactor the error handling
  - add mutex lock
  - Tested-at: https://travis-ci.org/williamtu/ovs-travis/builds/601947245

v4:
  Feedbacks from Eelco
  - Tested-at: https://travis-ci.org/williamtu/ovs-travis/builds/599308893

v3:
  Feedbacks from Ilya and Eelco
  - update doc, afxdp.rst
  - fix coding style
  - fix limit of numa node max, by using ovs_numa_numa_id_is_valid
  - move the function to netdev-linux
  - cache the result of numa_id
  - add security check for netdev name
  - use fscanf instead of read and convert to int
  - revise some error message content

v2:
  address feedback from Eelco
fix memory leak of xaspintf
log using INFO instead of WARN

---
 Documentation/intro/install/afxdp.rst |  1 -
 lib/netdev-afxdp.c| 11 -
 lib/netdev-afxdp.h|  1 -
 lib/netdev-linux-private.h|  2 +
 lib/netdev-linux.c| 67 +--
 5 files changed, 66 insertions(+), 16 deletions(-)

diff --git a/Documentation/intro/install/afxdp.rst 
b/Documentation/intro/install/afxdp.rst
index 15e3c918f942..7b0736c96114 100644
--- a/Documentation/intro/install/afxdp.rst
+++ b/Documentation/intro/install/afxdp.rst
@@ -327,7 +327,6 @@ Below is a script using namespaces and veth peer::
 
 Limitations/Known Issues
 
-#. Device's numa ID is always 0, need a way to find numa id from a netdev.
 #. No QoS support because AF_XDP netdev by-pass the Linux TC layer. A possible
work-around is to use OpenFlow meter action.
 #. Most of the tests are done using i40e single port. Multiple ports and
diff --git a/lib/netdev-afxdp.c b/lib/netdev-afxdp.c
index 58365ed483e3..426dce944977 100644
--- a/lib/netdev-afxdp.c
+++ b/lib/netdev-afxdp.c
@@ -703,17 +703,6 @@ out:
 return err;
 }
 
-int
-netdev_afxdp_get_numa_id(const struct netdev *netdev)
-{
-/* FIXME: Get netdev's PCIe device ID, then find
- * its NUMA node id.
- */
-VLOG_INFO("FIXME: Device %s always use numa id 0.",
-  netdev_get_name(netdev));
-return 0;
-}
-
 static void
 xsk_remove_xdp_program(uint32_t ifindex, enum afxdp_mode mode)
 {
diff --git a/lib/netdev-afxdp.h b/lib/netdev-afxdp.h
index ae6971efd113..e91cd102d284 100644
--- a/lib/netdev-afxdp.h
+++ b/lib/netdev-afxdp.h
@@ -61,7 +61,6 @@ int netdev_afxdp_batch_send(struct netdev *netdev_, int qid,
 int netdev_afxdp_set_config(struct netdev *netdev, const struct smap *args,
 char **errp);
 int netdev_afxdp_get_config(const struct netdev *netdev, struct smap *args);
-int netdev_afxdp_get_numa_id(const struct netdev *netdev);
 int netdev_afxdp_get_stats(const struct netdev *netdev_,
struct netdev_stats *stats);
 int netdev_afxdp_get_custom_stats(const struct netdev *netdev,
diff --git a/lib/netdev-linux-private.h b/lib/netdev-linux-private.h
index f08159aa7b53..55108d2c2e70 100644
--- a/lib/netdev-linux-private.h
+++ b/lib/netdev-linux-private.h
@@ -96,6 +96,8 @@ struct netdev_linux {
 /* LAG information. */
 bool is_lag_master; /* True if the netdev is a LAG master. */
 
+int numa_id;/* NUMA node id. */
+
 #ifdef HAVE_AF_XDP
 /* AF_XDP information. */
 struct xsk_socket_info **xsks;
diff --git a/lib/netdev-linux.c b/lib/netdev-linux.c
index 8a62f9d741ec..b29487e7c553 100644
--- a/lib/netdev-linux.c
+++ b/lib/netdev-linux.c
@@ -236,6 +236,7 @@ enum {
 VALID_VPORT_STAT_ERROR  = 1 << 5,
 VALID_DRVINFO   = 1 << 6,
 VALID_FEATURES  = 1 << 7,
+VAL

Re: [ovs-dev] [PATCH v8 2/2] netdev-afxdp: NUMA-aware memory allocation for XSK related memory

[Yi-Hung Wei]

On Fri, Jan 3, 2020 at 7:09 AM Ilya Maximets  wrote:
>
> On 18.12.2019 21:31, Yi-Hung Wei wrote:
> > --- a/lib/netdev-afxdp.c
> > +++ b/lib/netdev-afxdp.c
> > @@ -692,6 +701,10 @@ netdev_afxdp_reconfigure(struct netdev *netdev)
> >  netdev_change_seq_changed(netdev);
> >  out:
> >  ovs_mutex_unlock(&dev->mutex);
> > +if (old_bm) {
> > +numa_set_membind(old_bm);
>
> This will not return previous numa policy, it will set policy
> to membind, which might be not expected by the user.
>
> I don't see a valid wrapper for that, so it seems like the only
> way is to use get/set_mempolicy directly for restoring the original
> memory policy.

Thanks for pointing this out.  Yes, after checking on libnuma there is
not proper wrapper to export and restore the original memory policy .
I would use get/set_mempolicy to achieve that in the next version.

>
> BTW, you're not allowed to use any libnuma functions if !numa_available().
> You need to check it first somewhere.

Sure, I will add a check with numa_available() in the next version.

Thanks,

-Yi-Hung
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH] dpif-netlink: Fix dumping uninitialized netdev flow stats.

[Ilya Maximets]

dpif logging functions expects to be called after the operation.
log_flow_del_message() dumps flow stats on success which are not
initialized before the actual call to netdev_flow_del():

 Conditional jump or move depends on uninitialised value(s)
at 0x6090875: _itoa_word (_itoa.c:179)
by 0x6093F0D: vfprintf (vfprintf.c:1642)
by 0x60C090F: vsnprintf (vsnprintf.c:114)
by 0xE5E7EC: ds_put_format_valist (dynamic-string.c:155)
by 0xE5E755: ds_put_format (dynamic-string.c:142)
by 0xE5A5E6: dpif_flow_stats_format (dpif.c:903)
by 0xE5B708: log_flow_message (dpif.c:1763)
by 0xE5BCA4: log_flow_del_message (dpif.c:1809)
by 0xFA6076: try_send_to_netdev (dpif-netlink.c:2190)
by 0xFA0D3C: dpif_netlink_operate (dpif-netlink.c:2248)
by 0xE5AFAC: dpif_operate (dpif.c:1376)
by 0xDF176E: push_dp_ops (ofproto-dpif-upcall.c:2367)
by 0xDF04C8: push_ukey_ops (ofproto-dpif-upcall.c:2447)
by 0xDF008F: revalidator_sweep__ (ofproto-dpif-upcall.c:2805)
by 0xDF5DC6: revalidator_sweep (ofproto-dpif-upcall.c:2816)
by 0xDF1E83: udpif_revalidator (ofproto-dpif-upcall.c:949)
by 0xF3A3FE: ovsthread_wrapper (ovs-thread.c:383)
by 0x565F6DA: start_thread (pthread_create.c:463)
by 0x615988E: clone (clone.S:95)
  Uninitialised value was created by a stack allocation
at 0xDEFC24: revalidator_sweep__ (ofproto-dpif-upcall.c:2733)

Also, by calling the log functions after the actual operation we could
pass the real error code instead of reporting success unconditionally.

CC: Roi Dayan 
Fixes: 3cd99886191e ("dpif-netlink: Use dpif logging functions")
Signed-off-by: Ilya Maximets 
---
 lib/dpif-netlink.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/lib/dpif-netlink.c b/lib/dpif-netlink.c
index a08c2378a..25423e86c 100644
--- a/lib/dpif-netlink.c
+++ b/lib/dpif-netlink.c
@@ -2176,8 +2176,8 @@ try_send_to_netdev(struct dpif_netlink *dpif, struct 
dpif_op *op)
 break;
 }
 
-log_flow_put_message(&dpif->dpif, &this_module, put, 0);
 err = parse_flow_put(dpif, put);
+log_flow_put_message(&dpif->dpif, &this_module, put, err);
 break;
 }
 case DPIF_OP_FLOW_DEL: {
@@ -2187,9 +2187,9 @@ try_send_to_netdev(struct dpif_netlink *dpif, struct 
dpif_op *op)
 break;
 }
 
-log_flow_del_message(&dpif->dpif, &this_module, del, 0);
 err = netdev_ports_flow_del(dpif->dpif.dpif_class, del->ufid,
 del->stats);
+log_flow_del_message(&dpif->dpif, &this_module, del, err);
 break;
 }
 case DPIF_OP_FLOW_GET: {
@@ -2199,8 +2199,8 @@ try_send_to_netdev(struct dpif_netlink *dpif, struct 
dpif_op *op)
 break;
 }
 
-log_flow_get_message(&dpif->dpif, &this_module, get, 0);
 err = parse_flow_get(dpif, get);
+log_flow_get_message(&dpif->dpif, &this_module, get, err);
 break;
 }
 case DPIF_OP_EXECUTE:
-- 
2.17.1

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH] ofproto-dpif-upcall: Fix using uninitialized upcall hash.

[Ilya Maximets]

upcalls are allocated on stack and 'hash' field must be initialized
regardless of attribute existence because it will be used later.

 Conditional jump or move depends on uninitialised value(s)
at 0xFA74A7: dpif_netlink_encode_execute (dpif-netlink.c:1828)
by 0xFA6DE8: dpif_netlink_operate__ (dpif-netlink.c:1906)
by 0xFA612F: dpif_netlink_operate_chunks (dpif-netlink.c:2219)
by 0xFA0E36: dpif_netlink_operate (dpif-netlink.c:2275)
by 0xE5AFAC: dpif_operate (dpif.c:1376)
by 0xDF3922: handle_upcalls (ofproto-dpif-upcall.c:1615)
by 0xDF269B: recv_upcalls (ofproto-dpif-upcall.c:857)
by 0xDF1C49: udpif_upcall_handler (ofproto-dpif-upcall.c:759)
by 0xF3A3FE: ovsthread_wrapper (ovs-thread.c:383)
by 0x565F6DA: start_thread (pthread_create.c:463)
by 0x615988E: clone (clone.S:95)
  Uninitialised value was created by a stack allocation
at 0xDF2258: recv_upcalls (ofproto-dpif-upcall.c:773)

Fixes: 0442bfb11d6c ("ofproto-dpif-upcall: Echo HASH attribute back to 
datapath.")
Signed-off-by: Ilya Maximets 
---
 ofproto/ofproto-dpif-upcall.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/ofproto/ofproto-dpif-upcall.c b/ofproto/ofproto-dpif-upcall.c
index aac0554af..409286ab1 100644
--- a/ofproto/ofproto-dpif-upcall.c
+++ b/ofproto/ofproto-dpif-upcall.c
@@ -786,6 +786,7 @@ recv_upcalls(struct handler *handler)
 struct upcall *upcall = &upcalls[n_upcalls];
 struct flow *flow = &flows[n_upcalls];
 unsigned int mru = 0;
+uint64_t hash = 0;
 int error;
 
 ofpbuf_use_stub(recv_buf, recv_stubs[n_upcalls],
@@ -806,7 +807,7 @@ recv_upcalls(struct handler *handler)
 }
 
 if (dupcall->hash) {
-upcall->hash = nl_attr_get_u64(dupcall->hash);
+hash = nl_attr_get_u64(dupcall->hash);
 }
 
 error = upcall_receive(upcall, udpif->backer, &dupcall->packet,
@@ -830,6 +831,7 @@ recv_upcalls(struct handler *handler)
 upcall->key = dupcall->key;
 upcall->key_len = dupcall->key_len;
 upcall->ufid = &dupcall->ufid;
+upcall->hash = hash;
 
 upcall->out_tun_key = dupcall->out_tun_key;
 upcall->actions = dupcall->actions;
-- 
2.17.1

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH] ofproto-dpif: Fix using uninitialized execute hash.

[Ilya Maximets]

Most of callers doesn't initialize dpif_execute.hash leaving random
value from the stack.  And this random value used later while encoding
netlink message and might produce unwanted kernel behavior.

Fix that by fully initializing dpif_execute structure.  Using
designated initializers to avoid such issues in the future.

Fixes: 0442bfb11d6c ("ofproto-dpif-upcall: Echo HASH attribute back to 
datapath.")
Signed-off-by: Ilya Maximets 
---
 ofproto/ofproto-dpif.c | 113 ++---
 1 file changed, 50 insertions(+), 63 deletions(-)

diff --git a/ofproto/ofproto-dpif.c b/ofproto/ofproto-dpif.c
index b17c6cdca..d298e17cf 100644
--- a/ofproto/ofproto-dpif.c
+++ b/ofproto/ofproto-dpif.c
@@ -1073,7 +1073,6 @@ check_masked_set_action(struct dpif_backer *backer)
 {
 struct eth_header *eth;
 struct ofpbuf actions;
-struct dpif_execute execute;
 struct dp_packet packet;
 struct flow flow;
 int error;
@@ -1098,14 +1097,13 @@ check_masked_set_action(struct dpif_backer *backer)
 
 /* Execute the actions.  On older datapaths this fails with EINVAL, on
  * newer datapaths it succeeds. */
-execute.actions = actions.data;
-execute.actions_len = actions.size;
-execute.packet = &packet;
-execute.flow = &flow;
-execute.needs_help = false;
-execute.probe = true;
-execute.mtu = 0;
-
+struct dpif_execute execute = {
+.actions = actions.data,
+.actions_len = actions.size,
+.packet = &packet,
+.flow = &flow,
+.probe = true,
+};
 error = dpif_execute(backer->dpif, &execute);
 
 dp_packet_uninit(&packet);
@@ -1127,7 +1125,6 @@ check_trunc_action(struct dpif_backer *backer)
 {
 struct eth_header *eth;
 struct ofpbuf actions;
-struct dpif_execute execute;
 struct dp_packet packet;
 struct ovs_action_trunc *trunc;
 struct flow flow;
@@ -1152,14 +1149,13 @@ check_trunc_action(struct dpif_backer *backer)
 
 /* Execute the actions.  On older datapaths this fails with EINVAL, on
  * newer datapaths it succeeds. */
-execute.actions = actions.data;
-execute.actions_len = actions.size;
-execute.packet = &packet;
-execute.flow = &flow;
-execute.needs_help = false;
-execute.probe = true;
-execute.mtu = 0;
-
+struct dpif_execute execute = {
+.actions = actions.data,
+.actions_len = actions.size,
+.packet = &packet,
+.flow = &flow,
+.probe = true,
+};
 error = dpif_execute(backer->dpif, &execute);
 
 dp_packet_uninit(&packet);
@@ -1181,7 +1177,6 @@ check_trunc_action(struct dpif_backer *backer)
 static bool
 check_clone(struct dpif_backer *backer)
 {
-struct dpif_execute execute;
 struct eth_header *eth;
 struct flow flow;
 struct dp_packet packet;
@@ -1204,14 +1199,13 @@ check_clone(struct dpif_backer *backer)
 
 /* Execute the actions.  On older datapaths this fails with EINVAL, on
  * newer datapaths it succeeds. */
-execute.actions = actions.data;
-execute.actions_len = actions.size;
-execute.packet = &packet;
-execute.flow = &flow;
-execute.needs_help = false;
-execute.probe = true;
-execute.mtu = 0;
-
+struct dpif_execute execute = {
+.actions = actions.data,
+.actions_len = actions.size,
+.packet = &packet,
+.flow = &flow,
+.probe = true,
+};
 error = dpif_execute(backer->dpif, &execute);
 
 dp_packet_uninit(&packet);
@@ -1233,7 +1227,6 @@ check_clone(struct dpif_backer *backer)
 static bool
 check_ct_eventmask(struct dpif_backer *backer)
 {
-struct dpif_execute execute;
 struct dp_packet packet;
 struct ofpbuf actions;
 struct flow flow = {
@@ -1266,14 +1259,13 @@ check_ct_eventmask(struct dpif_backer *backer)
 
 /* Execute the actions.  On older datapaths this fails with EINVAL, on
  * newer datapaths it succeeds. */
-execute.actions = actions.data;
-execute.actions_len = actions.size;
-execute.packet = &packet;
-execute.flow = &flow;
-execute.needs_help = false;
-execute.probe = true;
-execute.mtu = 0;
-
+struct dpif_execute execute = {
+.actions = actions.data,
+.actions_len = actions.size,
+.packet = &packet,
+.flow = &flow,
+.probe = true,
+};
 error = dpif_execute(backer->dpif, &execute);
 
 dp_packet_uninit(&packet);
@@ -1328,7 +1320,6 @@ check_ct_clear(struct dpif_backer *backer)
 static bool
 check_ct_timeout_policy(struct dpif_backer *backer)
 {
-struct dpif_execute execute;
 struct dp_packet packet;
 struct ofpbuf actions;
 struct flow flow = {
@@ -1361,14 +1352,13 @@ check_ct_timeout_policy(struct dpif_backer *backer)
 
 /* Execute the actions.  On older datapaths this fails with EINVAL, on
  * newer datapaths it succeeds. */
-execute.actions = actions.data;
-execute.actions_len = actions.size;
-execute.packet = &packet;
-   

[ovs-dev] Good News

[Jeffrey Wayne Financial LLC]

Hello

I'm Jeffrey Wayne, a private/individual lender located in Nevada, United 
States,I lend money to borrowers nationwide and a few other countries overseas 
who are looking to develop their business. I offer personal loans, business 
loans & real estate loans etc

I am writing to see if you have any deal that needs funding. Kindly reply so we 
can discuss on closing some deals.

Regards,
Jeff.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH ovn 2/2] RA Route Info Option: copy route info string in order to avoid truncated value

[Lorenzo Bianconi]

ipv6_ra_send can run 2 times in a row before prepare_ipv6_ras updates
the route info. Clone route info string before running
packet_put_ra_route_info_opt in order to avoid sending truncated route
info on the wire.
Moreover move ip6_hdr definition just before accessing it because the
packet can be reallocated if the data area is not big enough for packet
content

Fixes: 9f7f466af ("Add support for Route Info Option in RA - RFC 4191")
Signed-off-by: Lorenzo Bianconi 
---
 controller/pinctrl.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/controller/pinctrl.c b/controller/pinctrl.c
index bb1f0ab5a..6a35a3c42 100644
--- a/controller/pinctrl.c
+++ b/controller/pinctrl.c
@@ -2468,7 +2468,6 @@ packet_put_ra_route_info_opt(struct dp_packet *b, 
ovs_be32 lifetime,
  char *route_list)
 {
 size_t prev_l4_size = dp_packet_l4_size(b);
-struct ip6_hdr *nh = dp_packet_l3(b);
 char *t0, *r0 = NULL;
 size_t size = 0;
 
@@ -2523,6 +2522,7 @@ packet_put_ra_route_info_opt(struct dp_packet *b, 
ovs_be32 lifetime,
 }
 }
 
+struct ip6_hdr *nh = dp_packet_l3(b);
 nh->ip6_plen = htons(prev_l4_size + size);
 struct ovs_ra_msg *ra = dp_packet_l4(b);
 ra->icmph.icmp6_cksum = 0;
@@ -2574,8 +2574,12 @@ ipv6_ra_send(struct rconn *swconn, struct ipv6_ra_state 
*ra)
 ds_destroy(&dnssl);
 }
 if (ra->config->route_info.length) {
+struct ds route_info;
+
+ds_clone(&route_info, &ra->config->route_info);
 packet_put_ra_route_info_opt(&packet, htonl(0x),
- ra->config->route_info.string);
+ ds_cstr(&route_info));
+ds_destroy(&route_info);
 }
 
 uint64_t ofpacts_stub[4096 / 8];
-- 
2.21.0

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH ovn 1/2] DNSSL: copy dnssl string in order to avoid truncated value

[Lorenzo Bianconi]

ipv6_ra_send can run 2 times in a row before prepare_ipv6_ras updates
the dnss list. Clone the dnss dynamic string before running
packet_put_ra_dnssl_opt in order to avoid sending truncated dnssl list
on the wire.
Moreover move ip6_hdr definition just before accessing it because the
packet can be reallocated if the data area is not big enough for packet
content

Fixes: 5a12a940f ("Add DNSSL support to OVN")
Signed-off-by: Lorenzo Bianconi 
---
 controller/pinctrl.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/controller/pinctrl.c b/controller/pinctrl.c
index c886b21d9..bb1f0ab5a 100644
--- a/controller/pinctrl.c
+++ b/controller/pinctrl.c
@@ -2417,7 +2417,6 @@ packet_put_ra_dnssl_opt(struct dp_packet *b, ovs_be32 
lifetime,
 {
 size_t prev_l4_size = dp_packet_l4_size(b);
 size_t size = sizeof(struct ovs_nd_dnssl);
-struct ip6_hdr *nh = dp_packet_l3(b);
 char *t0, *r0 = NULL, dnssl[255] = {};
 int i = 0;
 
@@ -2445,6 +2444,8 @@ packet_put_ra_dnssl_opt(struct dp_packet *b, ovs_be32 
lifetime,
 dnssl[i++] = 0;
 }
 size = ROUND_UP(size, 8);
+
+struct ip6_hdr *nh = dp_packet_l3(b);
 nh->ip6_plen = htons(prev_l4_size + size);
 
 struct ovs_nd_dnssl *nd_dnssl = dp_packet_put_uninit(b, sizeof *nd_dnssl);
@@ -2566,8 +2567,11 @@ ipv6_ra_send(struct rconn *swconn, struct ipv6_ra_state 
*ra)
 &ra->config->rdnss);
 }
 if (ra->config->dnssl.length) {
-packet_put_ra_dnssl_opt(&packet, htonl(0x),
-ra->config->dnssl.string);
+struct ds dnssl;
+
+ds_clone(&dnssl, &ra->config->dnssl);
+packet_put_ra_dnssl_opt(&packet, htonl(0x), ds_cstr(&dnssl));
+ds_destroy(&dnssl);
 }
 if (ra->config->route_info.length) {
 packet_put_ra_route_info_opt(&packet, htonl(0x),
-- 
2.21.0

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH ovn 0/2] fix DNSSL and Route Info Option in RA

[Lorenzo Bianconi]

Lorenzo Bianconi (2):
  DNSSL: copy dnssl string in order to avoid truncated value
  RA Route Info Option: copy route info string in order to avoid
truncated value

 controller/pinctrl.c | 18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

-- 
2.21.0

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] attaching ebpf program to openvswitch vport driver

[William Tu]

Hi Nicolas,

I was wrong. Actually with existing OVS internal device, the xdp generic mode
works fine.  Please see my test on kernel 5.3 below

#!/bin/bash
modprobe openvswitch
ovs-dpctl add-dp br0
ip addr add dev br0 10.1.1.2/24
ip link set dev br0 up

ip netns add at_ns0
ip link add p0 type veth peer name afxdp-p0
ip link set p0 netns at_ns0
ip link set dev afxdp-p0 up

ovs-dpctl add-if br0 afxdp-p0
ip netns exec at_ns0 sh << NS_EXEC_HEREDOC
ip addr add "10.1.1.1/24" dev p0
ip link set dev p0 up
NS_EXEC_HEREDOC

ovs-dpctl add-flow br0 "in_port(0),eth()" 1
ovs-dpctl add-flow br0 "in_port(1),eth()" 0

ping 10.1.1.1

Then insert the prog to drop
ip link set dev br0 xdpgeneric obj xdp1_kern.o sec xdp1
cat /sys/kernel/debug/tracing/trace_pipe
   <...>-91754 [001] ..s1 56247.205203: 0: xdp_prog1 pass
   <...>-91754 [001] ..s1 56248.229296: 0: xdp_prog1 pass

or remove the prog
ip link set dev br0 xdpgeneric off

Thanks
William

On Tue, Dec 17, 2019 at 9:22 AM Nicolas Bouliane
 wrote:
>
>
>>
>> In function internal_dev_recv, currently it calls
>> netif_rx(skb)
>> and this skips the generic xdp code path.
>>
>> I wonder if it's ok to replace netif_rx with
>> netif_receive_skb(skb)
>> Then the generic xdp should work.
>>
> Ohh, interesting, I'll check that !
> cheers,
> Nick
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH] netdev-offload-tc: Fix using uninitialized recirc_act.

[Ilya Maximets]

Fixes: b2ae40690ed7 ("netdev-offload-tc: Add recirculation support via tc 
chains")
Signed-off-by: Ilya Maximets 
---
 lib/netdev-offload-tc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/netdev-offload-tc.c b/lib/netdev-offload-tc.c
index 9e1c84d44..7453078d5 100644
--- a/lib/netdev-offload-tc.c
+++ b/lib/netdev-offload-tc.c
@@ -1365,10 +1365,10 @@ netdev_tc_flow_put(struct netdev *netdev, struct match 
*match,
 const struct flow_tnl *tnl = &match->flow.tunnel;
 const struct flow_tnl *tnl_mask = &mask->tunnel;
 struct tc_action *action;
+bool recirc_act = false;
 uint32_t block_id = 0;
 struct nlattr *nla;
 struct tcf_id id;
-bool recirc_act;
 uint32_t chain;
 size_t left;
 int prio = 0;
-- 
2.17.1

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH] tc: Fix using uninitialized id chain.

[Ilya Maximets]

tc_make_tcf_id() doesn't initialize the 'chain' field leaving it with a
random value from the stack.  This makes request_from_tcf_id() create
request with random TCA_CHAIN included.  These requests are obviously
doesn't work as needed leading to broken flow dump and various other
issues.  Fix that by using designated initializer instead.

Fixes: acdd544c4c9a ("tc: Introduce tcf_id to specify a tc filter")
Signed-off-by: Ilya Maximets 
---
 lib/tc.h | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/lib/tc.h b/lib/tc.h
index 70e7f38d2..d31c0953e 100644
--- a/lib/tc.h
+++ b/lib/tc.h
@@ -271,13 +271,12 @@ static inline struct tcf_id
 tc_make_tcf_id(int ifindex, uint32_t block_id, uint16_t prio,
enum tc_qdisc_hook hook)
 {
-struct tcf_id id;
-
-id.block_id = block_id;
-id.ifindex = ifindex;
-id.prio = prio;
-id.hook = hook;
-id.handle = 0;
+struct tcf_id id = {
+.hook = hook,
+.block_id = block_id,
+.ifindex = ifindex,
+.prio = prio,
+};
 
 return id;
 }
-- 
2.17.1

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH RFC] WIP: netdev-tpacket: Add AF_PACKET v3 support.

[William Tu]

On Fri, Jan 03, 2020 at 02:28:03PM +0100, Ilya Maximets wrote:
> On 03.01.2020 00:54, William Tu wrote:
> > On Mon, Dec 23, 2019 at 5:22 PM Yi Yang (杨燚)-云服务集团  
> > wrote:
> >>
> >> William, maybe you don't know that kind of tap interface you're saying 
> >> only can be used for VM, that is why openvswitch has to introduce internal 
> >> type for the case I'm saying.
> 
> There is no such thing as "only can be used for VM".
> QEMU creates usual tap interface and OVS could open
> it with AF_PACKET/XDP socket as usual.  See below.
> 
> >>
> >> In OVS DPDK case, if you create the below interface, it is a tap interface.
> >>
> >> ovs-vsctl add-port tapX -- set interface type=internal
> >>
> >> It won't work if you create tap interface in the below way
> >>
> >> Ip tuntap add tapX node tap
> >> ovs-vsctl add-port br-int tapX
> >>
> > Hi Yi,
> > 
> > I think this is mentioned in Documentation/faq/issues.rst,
> > see
> > Q: I created a tap device tap0, configured an IP address on it, and added 
> > it to
> > a bridge, like this::
> > 
> > $ tunctl -t tap0
> > $ ip addr add 192.168.0.123/24 dev tap0
> > $ ip link set tap0 up
> > $ ovs-vsctl add-br br0
> > $ ovs-vsctl add-port br0 tap0
> > 
> > I expected that I could then use this IP address to contact other hosts on 
> > the
> > network, but it doesn't work.  Why not?
> 
> You're doing something really strange here.  TUN/TAP interface
> is a way to communicate between userspace application that creates it
> and the kernel network stack.  In the command sequence above there is
> no application that actually listens on the other side of this
> tap0 network interface.  And it's effectively in DOWN state and
> can not be used.  'tunctl' just allows you to create a persistent
> tap interface that will survive restart of the owning application
> without loosing ip address and other configuration.
> 
>   $ tunctl -t tap0
>   $ ip addr add 192.168.0.123/24 dev tap0
>   $ ip link set tap0 up
>   $ ip link show tap0
> 5: tap0:  mtu 1500 qdisc pfifo_fast
>state DOWN mode DEFAULT group default qlen 1000
>link/ether 82:51:60:3a:08:e0 brd ff:ff:ff:ff:ff:ff
> 
> To make it work some application needs to open /dev/net/tun and
> perform an TUNSETIFF ioctl to open this or create new tap interface.
> OVS will not do that, it will just open usual AF_PACKET socket

> that will try to get packets from the DOWN kernel interface (interface
> type=system by default).
> Same will happen if you'll try to open it with type=afxdp.
> 
> OVS will open and configure the tap interface correctly only if you'll
> provide type=tap.  In this case, OVS will open /dev/net/tun and
> will perform TUNSETIFF ioctl to open persistent or create new tap
> interface. Retrieved tap_fd will be used for data transmission. After
> that tap0 will get the carrier and the state will finally become UP.
> (type=internal is equal to type=tap for userspace datapath).

Thanks, I tested it and it works OK if ovs-vsctl open the device with
type=internal or type=tap. Because OVS will re-open the /dev/net/tun
and get the tap fd. Below is my script:

ovs-vsctl -- add-br br0 -- set Bridge br0 datapath_type=netdev

ip tuntap add tap0 mode tap
tunctl -t tap1
ovs-vsctl add-port br0 tap0 -- set int tap0 type=internal
ovs-vsctl add-port br0 tap1 -- set int tap1 type=tap

ip netns add ns0
ip netns add ns1
ip link set tap0 netns ns0
ip link set tap1 netns ns1
ip netns exec ns0 ip addr add 10.1.1.1/24 dev tap0
ip netns exec ns1 ip addr add 10.1.1.2/24 dev tap1
ip netns exec ns0 ip link set dev tap0 up
ip netns exec ns1 ip link set dev tap1 up

ip netns exec ns0 ifconfig
ip netns exec ns0 ping 10.1.1.2

Regards,
William


> 
> In case of tap interface created by QEMU, OVS is able to open it with
> usual AF_PACKET/XDP socket just because QEMU is the userspace application
> that owns it (opens /dev/net/tun and performs TUNSETIFF ioctl).  The
> interface is in UP state as long as QEMU process alive.
> 
> TAP interface is not a stand-alone entity, it's a pipe between particular
> userspace application and the kernel network stack.  And it will obviously
> not work if you're connecting to it from the kernel side (via socket)
> without any application listening from the userspace.
> 
> Best regards, Ilya Maximets.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] Fiscalización del SAT a través de los CFDI

[Cierre de Inscripciones]

Webinar interactivo - Ideal para capacitar equipos de trabajo

El actual esquema de fiscalización del SAT a través de los CFDI
Miércoles 29 de Enero de 2020 | Horario de 10:00 a 17:00 hrs.
 
Nuestro webinar trata sobre el actual esquema de fiscalización y la 
determinación de diferencias por parte de la autoridad que pueden tener
 como consecuencia una opinión de cumplimiento negativa. 

Objetivo General:

Se analizarán, a través de casos prácticos, las discrepancias fiscales en las 
que se pueden incurrir por el incorrecto llenado de los comprobantes 
fiscales, así como su correcto registro en la contabilidad y cumpllir con todos 
los requisitos de deducibilidad. 
 
Que Aprenderás:

- Identificaremos los esquemas de fiscalización de la autoridad.
- Identificaremos los aspectos más delicados en la emisión de los CFDI, para 
evitar discrepancias fiscales.
- Práctica indebidas en la emisión de los CFDI. 
- Análisis de los repositorios y las fuentes de información de la página del 
SAT. 
 
¿Requiere la información a la brevedad?
Responda este email con la palabra SAT ,agregando los siguientes datos

NOMBRE:
TELÉFONO:
EMAIL: 

Centro telefónico:
(045) 55 15 54 66 30 - (045) 55 85567293 - (045) 5530167085 

En caso de que haya recibido este correo sin haberlo solicitado o si desea 
dejar de recibir nuestra promoción favor de responder con la palabra baja



___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] Greetings,

[MR. ROSS M. MCEWAN]

 Greetings,

Knowing one another is a gradual process My names are Mr. Ross Maxwell
MCewan,I would like to communicate with you write via this medium for
further introduction.


Best regard,

Mr. Ross M. McEwan,
Chief Executive Officer,
Royal Bank of Scotland Group Plc.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH RFC] WIP: netdev-tpacket: Add AF_PACKET v3 support.

[William Tu]

On Fri, Jan 3, 2020 at 5:28 AM Ilya Maximets  wrote:
>
> On 03.01.2020 00:54, William Tu wrote:
> > On Mon, Dec 23, 2019 at 5:22 PM Yi Yang (杨燚)-云服务集团  
> > wrote:
> >>
> >> William, maybe you don't know that kind of tap interface you're saying 
> >> only can be used for VM, that is why openvswitch has to introduce internal 
> >> type for the case I'm saying.
>
> There is no such thing as "only can be used for VM".
> QEMU creates usual tap interface and OVS could open
> it with AF_PACKET/XDP socket as usual.  See below.
>
> >>
> >> In OVS DPDK case, if you create the below interface, it is a tap interface.
> >>
> >> ovs-vsctl add-port tapX -- set interface type=internal
> >>
> >> It won't work if you create tap interface in the below way
> >>
> >> Ip tuntap add tapX node tap
> >> ovs-vsctl add-port br-int tapX
> >>
> > Hi Yi,
> >
> > I think this is mentioned in Documentation/faq/issues.rst,
> > see
> > Q: I created a tap device tap0, configured an IP address on it, and added 
> > it to
> > a bridge, like this::
> >
> > $ tunctl -t tap0
> > $ ip addr add 192.168.0.123/24 dev tap0
> > $ ip link set tap0 up
> > $ ovs-vsctl add-br br0
> > $ ovs-vsctl add-port br0 tap0
> >
> > I expected that I could then use this IP address to contact other hosts on 
> > the
> > network, but it doesn't work.  Why not?
>
> You're doing something really strange here.  TUN/TAP interface
> is a way to communicate between userspace application that creates it
> and the kernel network stack.  In the command sequence above there is
> no application that actually listens on the other side of this
> tap0 network interface.  And it's effectively in DOWN state and
> can not be used.  'tunctl' just allows you to create a persistent
> tap interface that will survive restart of the owning application
> without loosing ip address and other configuration.
>
>   $ tunctl -t tap0
>   $ ip addr add 192.168.0.123/24 dev tap0
>   $ ip link set tap0 up
>   $ ip link show tap0
> 5: tap0:  mtu 1500 qdisc pfifo_fast
>state DOWN mode DEFAULT group default qlen 1000
>link/ether 82:51:60:3a:08:e0 brd ff:ff:ff:ff:ff:ff
>
> To make it work some application needs to open /dev/net/tun and
> perform an TUNSETIFF ioctl to open this or create new tap interface.
> OVS will not do that, it will just open usual AF_PACKET socket
> that will try to get packets from the DOWN kernel interface (interface
> type=system by default).
> Same will happen if you'll try to open it with type=afxdp.
>
> OVS will open and configure the tap interface correctly only if you'll
> provide type=tap.  In this case, OVS will open /dev/net/tun and
> will perform TUNSETIFF ioctl to open persistent or create new tap
> interface. Retrieved tap_fd will be used for data transmission. After
> that tap0 will get the carrier and the state will finally become UP.
> (type=internal is equal to type=tap for userspace datapath).
>
> In case of tap interface created by QEMU, OVS is able to open it with
> usual AF_PACKET/XDP socket just because QEMU is the userspace application
> that owns it (opens /dev/net/tun and performs TUNSETIFF ioctl).  The
> interface is in UP state as long as QEMU process alive.
>
> TAP interface is not a stand-alone entity, it's a pipe between particular
> userspace application and the kernel network stack.  And it will obviously
> not work if you're connecting to it from the kernel side (via socket)
> without any application listening from the userspace.
>
Thanks Ilya!
Lots of people get confused when using tap device and internal.
It's very clear with you explanation!
Do you want to consider adding these text to Documentation/faq/issues.rst?

William
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v18] Improved Packet Drop Statistics in OVS

[Federico Iezzi]

> 
> On 18 Dec 2019, at 3:20 pm, Ilya Maximets  wrote:
> 
> On 18.12.2019 05:48, Anju Thomas wrote:
>> Currently OVS maintains explicit packet drop/error counters only on port
>> level.  Packets that are dropped as part of normal OpenFlow processing
>> are counted in flow stats of “drop” flows or as table misses in table
>> stats. These can only be interpreted by controllers that know the
>> semantics of the configured OpenFlow pipeline.  Without that knowledge,
>> it is impossible for an OVS user to obtain e.g. the total number of
>> packets dropped due to OpenFlow rules.
>> 
>> Furthermore, there are numerous other reasons for which packets can be
>> dropped by OVS slow path that are not related to the OpenFlow pipeline.
>> The generated datapath flow entries include a drop action to avoid
>> further expensive upcalls to the slow path, but subsequent packets
>> dropped by the datapath are not accounted anywhere.
>> 
>> Finally, the datapath itself drops packets in certain error situations.
>> Also, these drops are today not accounted for.This makes it difficult
>> for OVS users to monitor packet drop in an OVS instance and to alert a
>> management system in case of a unexpected increase of such drops.
>> AlsoOVS trouble-shooters face difficulties in analysing packet drops.
>> 
>> With this patch we implement following changes to address the issues
>> mentioned above.
>> 
>> 1. Identify and account all the silent packet drop scenarios
>> 
>> 2. Display these drops in ovs-appctl coverage/show
>> 
>> Co-authored-by: Rohith Basavaraja 
>> Co-authored-by: Keshav Gupta 
>> Signed-off-by: Anju Thomas 
>> Signed-off-by: Rohith Basavaraja 
>> Signed-off-by: Keshav Gupta 
>> Acked-by: Eelco Chaudron > ---
> 
> Thanks.  This version looks OK to me beside the fact that I'd rename
> the patch to something like "userspace: Improved packet drop statistics.",
> but this is minor.  One more thing is that we might want to rename
> 'enum xlate_error' to 'enum ovs_xlate_error' and prefix all its members
> with 'OVS_' to keep the style along with kernel definitions, but this is
> a mechanical change that could be done later in a separate patch as it
> will touch a lot of unrelated code.
> 
> Acked-by: Ilya Maximets 
> 
> Hi Ben,
> could you, please, take a look at this patch one more time?
> There were a couple of changes as we moved 'enum xlate_error' to
> openvswitch.h header to avoid inclusion of 'ofproto/ofproto-dpif-xlate.h'
> from the 'lib' code, new datapath capability was documented and we
> cleaned the patch up a little bit.

Any news? We’re finally this close for merging the patch set.

> 
> BTW, I will be traveling starting from tomorrow until the end of next
> week, so feel free to apply this patch if it looks good to you.  I could
> apply it myself today (if you could reply on it today) or after my trip.
> 
> Best regards, Ilya Maximets.
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH] ofproto-dpif-trace: Improve NAT tracing.

[Dumitru Ceara]

When ofproto/trace detects a recirc action it resumes execution at the
specified next table. However, if the ct action performs SNAT/DNAT,
e.g., ct(commit,nat(src=1.1.1.1:4000),table=42), the src/dst IPs and
ports in the oftrace_recirc_node->flow field are not updated. This leads
to misleading outputs from ofproto/trace as real packets would actually
first get NATed and might match different flows when recirculated.

Assume the first IP/port from the NAT src/dst action will be used by
conntrack for the translation and update the oftrace_recirc_node->flow
accordingly. This is not entirely correct as conntrack might choose a
different IP/port but the result is more realistic than before.

This fix covers new connections. However, for reply traffic that executes
actions of the form ct(nat, table=42) we still don't update the flow as
we don't have any information about conntrack state when tracing.

Signed-off-by: Dumitru Ceara 
---
 ofproto/ofproto-dpif-trace.c | 33 +
 ofproto/ofproto-dpif-trace.h |  1 +
 ofproto/ofproto-dpif-xlate.c |  6 --
 tests/ofproto-dpif.at| 36 
 4 files changed, 74 insertions(+), 2 deletions(-)

diff --git a/ofproto/ofproto-dpif-trace.c b/ofproto/ofproto-dpif-trace.c
index 8ae8a22..b2ff903 100644
--- a/ofproto/ofproto-dpif-trace.c
+++ b/ofproto/ofproto-dpif-trace.c
@@ -86,6 +86,7 @@ oftrace_node_destroy(struct oftrace_node *node)
 bool
 oftrace_add_recirc_node(struct ovs_list *recirc_queue,
 enum oftrace_recirc_type type, const struct flow *flow,
+const struct ofpact_nat *ofn,
 const struct dp_packet *packet, uint32_t recirc_id,
 const uint16_t zone)
 {
@@ -101,6 +102,38 @@ oftrace_add_recirc_node(struct ovs_list *recirc_queue,
 node->flow = *flow;
 node->flow.recirc_id = recirc_id;
 node->flow.ct_zone = zone;
+
+/* If there's any snat/dnat information assume we always translate to
+ * the first IP/port to make sure we don't match on incorrect flows later
+ * on.
+ */
+if (ofn) {
+if (ofn->flags & NX_NAT_F_SRC) {
+if (ofn->range_af == AF_INET) {
+node->flow.nw_src = ofn->range.addr.ipv4.min;
+} else if (ofn->range_af == AF_INET6) {
+memcpy(&node->flow.ipv6_src, &ofn->range.addr.ipv6.min,
+   sizeof node->flow.ipv6_src);
+}
+
+if (ofn->range_af != AF_UNSPEC && ofn->range.proto.min) {
+node->flow.tp_src = htons(ofn->range.proto.min);
+}
+}
+if (ofn->flags & NX_NAT_F_DST) {
+if (ofn->range_af == AF_INET) {
+node->flow.nw_dst = ofn->range.addr.ipv4.min;
+} else if (ofn->range_af == AF_INET6) {
+memcpy(&node->flow.ipv6_dst, &ofn->range.addr.ipv6.min,
+   sizeof node->flow.ipv6_dst);
+}
+
+if (ofn->range_af != AF_UNSPEC && ofn->range.proto.min) {
+node->flow.tp_dst = htons(ofn->range.proto.min);
+}
+}
+}
+
 node->packet = packet ? dp_packet_clone(packet) : NULL;
 
 return true;
diff --git a/ofproto/ofproto-dpif-trace.h b/ofproto/ofproto-dpif-trace.h
index 63dbb50..e5db9f9 100644
--- a/ofproto/ofproto-dpif-trace.h
+++ b/ofproto/ofproto-dpif-trace.h
@@ -91,6 +91,7 @@ struct oftrace_node *oftrace_report(struct ovs_list *, enum 
oftrace_node_type,
 const char *text);
 bool oftrace_add_recirc_node(struct ovs_list *recirc_queue,
  enum oftrace_recirc_type, const struct flow *,
+ const struct ofpact_nat *,
  const struct dp_packet *, uint32_t recirc_id,
  const uint16_t zone);
 
diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
index 1c72693..ac73656 100644
--- a/ofproto/ofproto-dpif-xlate.c
+++ b/ofproto/ofproto-dpif-xlate.c
@@ -4968,7 +4968,8 @@ compose_recirculate_and_fork(struct xlate_ctx *ctx, 
uint8_t table,
 if (OVS_UNLIKELY(ctx->xin->trace) && recirc_id) {
 if (oftrace_add_recirc_node(ctx->xin->recirc_queue,
 OFT_RECIRC_CONNTRACK, &ctx->xin->flow,
-ctx->xin->packet, recirc_id, zone)) {
+ctx->ct_nat_action, ctx->xin->packet,
+recirc_id, zone)) {
 xlate_report(ctx, OFT_DETAIL, "A clone of the packet is forked to "
  "recirculate. The forked pipeline will be resumed at "
  "table %u.", table);
@@ -6151,7 +6152,6 @@ compose_conntrack_action(struct xlate_ctx *ctx, struct 
ofpact_conntrack *ofc,
 put_ct_label(&ctx->xin->flow, ctx->odp_actions, ctx->wc);
 put_ct_helper(ctx, ctx->odp_actions, ofc);
 put_ct_n

Re: [ovs-dev] [PATCH v8 2/2] netdev-afxdp: NUMA-aware memory allocation for XSK related memory

[Ilya Maximets]

On 18.12.2019 21:31, Yi-Hung Wei wrote:
> Currently, the AF_XDP socket (XSK) related memory are allocated by main
> thread in the main thread's NUMA domain.  With the patch that detects
> netdev-linux's NUMA node id, the PMD thread of AF_XDP port will be run on
> the AF_XDP netdev's NUMA domain.  If the net device's NUMA domain
> is different from the main thread's NUMA domain, we will have two
> cross-NUMA memory accesses (netdev <-> memory, memory <-> CPU).
> 
> This patch addresses the aforementioned issue by allocating
> the memory in the net device's NUMA domain.
> 
> Signed-off-by: Yi-Hung Wei 
> ---
> v8:
>   - Addreess review comments from Eelco and Ilya in patch 2.
> * Use OVS_FIND_DEPENDENCY().
> * Avoid the locking issue when calling netdev_get_numa_id().
> * Check NETDEV_NUMA_UNSPEC.
> * Use return value from netdev_get_numa_id() directly, and
>   check NETDEV_NUMA_UNSPEC case.
> * Use numa_set_preferred().
> 
> ---
>  Documentation/intro/install/afxdp.rst |  2 +-
>  acinclude.m4  |  2 ++
>  include/sparse/automake.mk|  1 +
>  include/sparse/numa.h | 27 +++
>  lib/netdev-afxdp.c| 13 +
>  5 files changed, 44 insertions(+), 1 deletion(-)
>  create mode 100644 include/sparse/numa.h
> 
> diff --git a/Documentation/intro/install/afxdp.rst 
> b/Documentation/intro/install/afxdp.rst
> index 7b0736c96114..c4685fa7ebac 100644
> --- a/Documentation/intro/install/afxdp.rst
> +++ b/Documentation/intro/install/afxdp.rst
> @@ -164,7 +164,7 @@ If a test case fails, check the log at::
>  
>  Setup AF_XDP netdev
>  ---
> -Before running OVS with AF_XDP, make sure the libbpf and libelf are
> +Before running OVS with AF_XDP, make sure the libbpf, libelf, and libnuma are
>  set-up right::
>  
>ldd vswitchd/ovs-vswitchd
> diff --git a/acinclude.m4 b/acinclude.m4
> index 542637ac8cb8..f73dc9bf7e3c 100644
> --- a/acinclude.m4
> +++ b/acinclude.m4
> @@ -286,6 +286,8 @@ AC_DEFUN([OVS_CHECK_LINUX_AF_XDP], [
>  AC_CHECK_FUNCS([pthread_spin_lock], [],
>[AC_MSG_ERROR([unable to find pthread_spin_lock for AF_XDP support])])
>  
> +OVS_FIND_DEPENDENCY([numa_alloc_onnode], [numa], [libnuma])
> +
>  AC_DEFINE([HAVE_AF_XDP], [1],
>[Define to 1 if AF_XDP support is available and enabled.])
>  LIBBPF_LDADD=" -lbpf -lelf"
> diff --git a/include/sparse/automake.mk b/include/sparse/automake.mk
> index 073631e8c082..974ad3fe55f7 100644
> --- a/include/sparse/automake.mk
> +++ b/include/sparse/automake.mk
> @@ -5,6 +5,7 @@ noinst_HEADERS += \
>  include/sparse/bits/floatn.h \
>  include/sparse/assert.h \
>  include/sparse/math.h \
> +include/sparse/numa.h \
>  include/sparse/netinet/in.h \
>  include/sparse/netinet/ip6.h \
>  include/sparse/netpacket/packet.h \
> diff --git a/include/sparse/numa.h b/include/sparse/numa.h
> new file mode 100644
> index ..3691a0eaf729
> --- /dev/null
> +++ b/include/sparse/numa.h
> @@ -0,0 +1,27 @@
> +/*
> + * Copyright (c) 2019 Nicira, Inc.
> + *
> + * Licensed under the Apache License, Version 2.0 (the "License");
> + * you may not use this file except in compliance with the License.
> + * You may obtain a copy of the License at:
> + *
> + * http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing, software
> + * distributed under the License is distributed on an "AS IS" BASIS,
> + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> + * See the License for the specific language governing permissions and
> + * limitations under the License.
> + */
> +
> +#ifndef __CHECKER__
> +#error "Use this header only with sparse.  It is not a correct 
> implementation."
> +#endif
> +
> +/* Avoid sparse warning: non-ANSI function declaration of function" */
> +#define numa_get_membind_compat() numa_get_membind_compat(void)
> +#define numa_get_interleave_mask_compat() 
> numa_get_interleave_mask_compat(void)
> +#define numa_get_run_node_mask_compat() numa_get_run_node_mask_compat(void)
> +
> +/* Get actual  definitions for us to annotate and build on. */
> +#include_next
> diff --git a/lib/netdev-afxdp.c b/lib/netdev-afxdp.c
> index 91b70b298e57..9a7dd8208f8f 100644
> --- a/lib/netdev-afxdp.c
> +++ b/lib/netdev-afxdp.c
> @@ -26,6 +26,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -661,6 +662,14 @@ netdev_afxdp_reconfigure(struct netdev *netdev)
>  struct rlimit r = {RLIM_INFINITY, RLIM_INFINITY};
>  int err = 0;
>  
> +/* Allocate all the xsk related memory in the netdev's NUMA domain. */
> +struct bitmask *old_bm = NULL;
> +int numa_id = netdev_get_numa_id(netdev);
> +if (numa_id != NETDEV_NUMA_UNSPEC) {
> +old_bm = numa_get_membind();
> +numa_set_preferred(numa_id);
> +}
> +
>   

Re: [ovs-dev] [PATCH 1/1] vswitchd: Allow setting MAC on DPDK interfaces

[Ilya Maximets]

On 23.12.2019 22:34, Eveline Raine wrote:
> When setting mac address for an interface using ovs-vsctl command:
> 
> ovs-vsctl set interface  mac=XX:XX:XX:XX:XX:XX
> 
> iface_set_mac() is responsible to delegate a request to set MAC to a
> netdev-specific set_etheraddr().
> 
> At the moment iface_set_mac() skips all interfaces except those with
> type = "internal", making it impossible to change MAC on any DPDK port.
> Since DPDK ports are owned by the OVS process, OVSDB can be considered
> the source of truth for them. In particular, the source of truth for
> their MAC addresses - so, OVS can take responsibility for setting them.
> 
> Therefore this check is extended to "dpdk" type.
> 
> Acked-by: Roni Bar Yanai 
> Tested-by: Adrian Chiris 
> Signed-off-by: Eveline Raine 
> ---
>  vswitchd/bridge.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/vswitchd/bridge.c b/vswitchd/bridge.c
> index 5de0a264a..355364afd 100644
> --- a/vswitchd/bridge.c
> +++ b/vswitchd/bridge.c
> @@ -4696,7 +4696,7 @@ iface_set_mac(const struct bridge *br, const struct 
> port *port, struct iface *if
>  struct eth_addr ea, *mac = NULL;
>  struct iface *hw_addr_iface;
>  
> -if (strcmp(iface->type, "internal")) {
> +if (strcmp(iface->type, "internal") && strcmp(iface->type, "dpdk")) {

Hmm... Interesting.  I didn't look at this code closely before and it
actually allows setting mac only for internal ports.

Allowing only dpdk port types here doesn't seem right.  Why not allowing
all the port types?

The issue I can see in this code is that OVS inherits MACs for internal
ports from the physical ones, i.e. if we're changing the MAC of a physical
port we need to re-check all the internal ports and update their addresses.

This might happen almost automatically on linux since we probably will
receive if-notifier event about MAC changing and OVS will trigger re-applying
of the bridge configuration.  However, this will not happen in DPDK case.
Recently introduced manual if-notifier could help here, I guess.
But all of this needs to be tested.

Ben, do you see any other drawbacks that we should handle if we'll allow
changing MAC addresses for non-internal ports?  Or, maybe some issues with
my logic?

Best regards, Ilya Maximets.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH RFC] WIP: netdev-tpacket: Add AF_PACKET v3 support.

[Ilya Maximets]

On 03.01.2020 00:54, William Tu wrote:
> On Mon, Dec 23, 2019 at 5:22 PM Yi Yang (杨燚)-云服务集团  
> wrote:
>>
>> William, maybe you don't know that kind of tap interface you're saying only 
>> can be used for VM, that is why openvswitch has to introduce internal type 
>> for the case I'm saying.

There is no such thing as "only can be used for VM".
QEMU creates usual tap interface and OVS could open
it with AF_PACKET/XDP socket as usual.  See below.

>>
>> In OVS DPDK case, if you create the below interface, it is a tap interface.
>>
>> ovs-vsctl add-port tapX -- set interface type=internal
>>
>> It won't work if you create tap interface in the below way
>>
>> Ip tuntap add tapX node tap
>> ovs-vsctl add-port br-int tapX
>>
> Hi Yi,
> 
> I think this is mentioned in Documentation/faq/issues.rst,
> see
> Q: I created a tap device tap0, configured an IP address on it, and added it 
> to
> a bridge, like this::
> 
> $ tunctl -t tap0
> $ ip addr add 192.168.0.123/24 dev tap0
> $ ip link set tap0 up
> $ ovs-vsctl add-br br0
> $ ovs-vsctl add-port br0 tap0
> 
> I expected that I could then use this IP address to contact other hosts on the
> network, but it doesn't work.  Why not?

You're doing something really strange here.  TUN/TAP interface
is a way to communicate between userspace application that creates it
and the kernel network stack.  In the command sequence above there is
no application that actually listens on the other side of this
tap0 network interface.  And it's effectively in DOWN state and
can not be used.  'tunctl' just allows you to create a persistent
tap interface that will survive restart of the owning application
without loosing ip address and other configuration.

  $ tunctl -t tap0
  $ ip addr add 192.168.0.123/24 dev tap0
  $ ip link set tap0 up
  $ ip link show tap0
5: tap0:  mtu 1500 qdisc pfifo_fast
   state DOWN mode DEFAULT group default qlen 1000
   link/ether 82:51:60:3a:08:e0 brd ff:ff:ff:ff:ff:ff

To make it work some application needs to open /dev/net/tun and
perform an TUNSETIFF ioctl to open this or create new tap interface.
OVS will not do that, it will just open usual AF_PACKET socket
that will try to get packets from the DOWN kernel interface (interface
type=system by default).
Same will happen if you'll try to open it with type=afxdp.

OVS will open and configure the tap interface correctly only if you'll
provide type=tap.  In this case, OVS will open /dev/net/tun and
will perform TUNSETIFF ioctl to open persistent or create new tap
interface. Retrieved tap_fd will be used for data transmission. After
that tap0 will get the carrier and the state will finally become UP.
(type=internal is equal to type=tap for userspace datapath).

In case of tap interface created by QEMU, OVS is able to open it with
usual AF_PACKET/XDP socket just because QEMU is the userspace application
that owns it (opens /dev/net/tun and performs TUNSETIFF ioctl).  The
interface is in UP state as long as QEMU process alive.

TAP interface is not a stand-alone entity, it's a pipe between particular
userspace application and the kernel network stack.  And it will obviously
not work if you're connecting to it from the kernel side (via socket)
without any application listening from the userspace.

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.

[Ilya Maximets]

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.

Best regards, Ilya Maximets.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev