[ovs-dev] WE NEED YOUR PRODUCTS
-- Dear Sir, We are Located in the united kingdom, the famous brand John Lewis PLC, is UK's largest multi-channel retailer with over 45 shops furnished with European products. We are looking for new products to attract new customers and also retain our existing ones, create new partnerships with companies dealing with different kinds of goods. Please send us your catalog through email to speed up and to learn more about your company's products and wholesale quote. We hope to be able to order with you and start long-term friendly, respectable and solid business partnership. We count on the reliability for both sides. We commit ourselves to a successful and professional processing for a good cooperation in all ranges. Could you also send to us all information required to become one of your regular distributors in Europe and worldwide? Please, we would appreciate if you could send us your stock availability via email. We will also pleased to receive any offers or proposals from other product available and ready (Stocks and rates). Payment: Our Payment Terms is within 15 days net in Europe and 30 days net in UK as we operate with all our suppliers. Best Regards, PATRICK LEWIS PURCHASING DIRECTOR PURCHASING DEPARTMENT customer service: 08006112981 Directline: +44 7709293519 Fax : +44 020 7629 7711 www.johnlewis.com -Loaded- Registered in England and Wales Registered No: 0233462 - VAT No : GB 232457280 This e-mail is confidential and intended only for the addresses shown. If you are not an intended recipient, please be advised that any use, dissemination, forwarding or copying of this e-mail is strictly prohibited. Internet e-mails are not necessarily secure and John Lewis Plc Uk does not accept responsibility for changes made to this message after it was sent. Please note that incoming and outgoing electronic mail messages may be monitored. Should you receive this transmission in error, notify the sender immediately. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH] Use batch process recv for tap and raw socket in netdev datapath
From: Yi Yang
Current netdev_linux_rxq_recv_tap and netdev_linux_rxq_recv_sock
just receive single packet, that is very inefficient, per my test
case which adds two tap ports or veth ports into OVS bridge
(datapath_type=netdev) and use iperf3 to do performance test
between two ports (they are set into different network name space).
The result is as below:
tap: 295 Mbits/sec
veth: 207 Mbits/sec
After I change netdev_linux_rxq_recv_tap and
netdev_linux_rxq_recv_sock to use batch process, the performance
is boosted by about 7 times, here is the result:
tap: 1.96 Gbits/sec
veth: 1.47 Gbits/sec
Undoubtedly this is a huge improvement although it can't match
OVS kernel datapath yet.
FYI: here is thr result for OVS kernel datapath:
tap: 37.2 Gbits/sec
veth: 36.3 Gbits/sec
Note: performance result is highly related with your test machine
, you shouldn't expect the same results on your test machine.
Signed-off-by: Yi Yang
---
lib/netdev-linux.c | 166 ++---
1 file changed, 108 insertions(+), 58 deletions(-)
diff --git a/lib/netdev-linux.c b/lib/netdev-linux.c
index f8e59ba..9cb45d5 100644
--- a/lib/netdev-linux.c
+++ b/lib/netdev-linux.c
@@ -1151,90 +1151,146 @@ auxdata_has_vlan_tci(const struct tpacket_auxdata *aux)
return aux->tp_vlan_tci || aux->tp_status & TP_STATUS_VLAN_VALID;
}
+/*
+ * Receive packets from raw socket in batch process for better performance,
+ * it can receive NETDEV_MAX_BURST packets at most once, the received
+ * packets are added into *batch. The return value is 0 or errno.
+ *
+ * It also used recvmmsg to reduce multiple syscalls overhead;
+ */
static int
-netdev_linux_rxq_recv_sock(int fd, struct dp_packet *buffer)
+netdev_linux_batch_rxq_recv_sock(int fd, int mtu,
+ struct dp_packet_batch *batch)
{
size_t size;
ssize_t retval;
-struct iovec iov;
+struct iovec iovs[NETDEV_MAX_BURST];
struct cmsghdr *cmsg;
union {
struct cmsghdr cmsg;
char buffer[CMSG_SPACE(sizeof(struct tpacket_auxdata))];
-} cmsg_buffer;
-struct msghdr msgh;
-
-/* Reserve headroom for a single VLAN tag */
-dp_packet_reserve(buffer, VLAN_HEADER_LEN);
-size = dp_packet_tailroom(buffer);
-
-iov.iov_base = dp_packet_data(buffer);
-iov.iov_len = size;
-msgh.msg_name = NULL;
-msgh.msg_namelen = 0;
-msgh.msg_iov =
-msgh.msg_iovlen = 1;
-msgh.msg_control = _buffer;
-msgh.msg_controllen = sizeof cmsg_buffer;
-msgh.msg_flags = 0;
+} cmsg_buffers[NETDEV_MAX_BURST];
+struct mmsghdr mmsgs[NETDEV_MAX_BURST];
+struct dp_packet *buffers[NETDEV_MAX_BURST];
+int i;
+
+for (i = 0; i < NETDEV_MAX_BURST; i++) {
+ buffers[i] = dp_packet_new_with_headroom(VLAN_ETH_HEADER_LEN + mtu,
+ DP_NETDEV_HEADROOM);
+ /* Reserve headroom for a single VLAN tag */
+ dp_packet_reserve(buffers[i], VLAN_HEADER_LEN);
+ size = dp_packet_tailroom(buffers[i]);
+ iovs[i].iov_base = dp_packet_data(buffers[i]);
+ iovs[i].iov_len = size;
+ mmsgs[i].msg_hdr.msg_name = NULL;
+ mmsgs[i].msg_hdr.msg_namelen = 0;
+ mmsgs[i].msg_hdr.msg_iov = [i];
+ mmsgs[i].msg_hdr.msg_iovlen = 1;
+ mmsgs[i].msg_hdr.msg_control = _buffers[i];
+ mmsgs[i].msg_hdr.msg_controllen = sizeof cmsg_buffers[i];
+ mmsgs[i].msg_hdr.msg_flags = 0;
+}
do {
-retval = recvmsg(fd, , MSG_TRUNC);
+retval = recvmmsg(fd, mmsgs, NETDEV_MAX_BURST, MSG_TRUNC, NULL);
} while (retval < 0 && errno == EINTR);
if (retval < 0) {
-return errno;
-} else if (retval > size) {
-return EMSGSIZE;
+/* Save -errno to retval temporarily */
+retval = -errno;
+goto free_buffers;
}
-dp_packet_set_size(buffer, dp_packet_size(buffer) + retval);
-
-for (cmsg = CMSG_FIRSTHDR(); cmsg; cmsg = CMSG_NXTHDR(, cmsg)) {
-const struct tpacket_auxdata *aux;
-
-if (cmsg->cmsg_level != SOL_PACKET
-|| cmsg->cmsg_type != PACKET_AUXDATA
-|| cmsg->cmsg_len < CMSG_LEN(sizeof(struct tpacket_auxdata))) {
-continue;
+for (i = 0; i < retval; i++) {
+if (mmsgs[i].msg_len < ETH_HEADER_LEN) {
+break;
}
-aux = ALIGNED_CAST(struct tpacket_auxdata *, CMSG_DATA(cmsg));
-if (auxdata_has_vlan_tci(aux)) {
-struct eth_header *eth;
-bool double_tagged;
+dp_packet_set_size(buffers[i],
+ dp_packet_size(buffers[i]) + mmsgs[i].msg_len);
+
+for (cmsg = CMSG_FIRSTHDR([i].msg_hdr); cmsg;
+ cmsg = CMSG_NXTHDR([i].msg_hdr, cmsg)) {
+const struct tpacket_auxdata *aux;
-if (retval < ETH_HEADER_LEN) {
-return EINVAL;
+if (cmsg->cmsg_level != SOL_PACKET
+
Re: [ovs-dev] compiling on v5.4 kernel
On Thu, Dec 05, 2019 at 04:29:12PM -0800, Gregory Rose wrote: > I tried building against the 5.4.2 kernel from kernel.org and found the inet > frags issue that David pointed out > To see if there were any other problems I then I ran 'make -i' but found > nothing else. It should just be > a compat layer fixup for the inet frags issue. Sounds great! As a side note, I hadn't run into "make -i" before, but I build with "make -k" as part of my standard "make" command. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCHv4] userspace: Add GTP-U support.
On Thu, Dec 05, 2019 at 12:43:31PM -0800, William Tu wrote:
> GTP, GPRS Tunneling Protocol, is a group of IP-based communications
> protocols used to carry general packet radio service (GPRS) within
> GSM, UMTS and LTE networks. GTP protocol has two parts: Signalling
> (GTP-Control, GTP-C) and User data (GTP-User, GTP-U). GTP-C is used
> for setting up GTP-U protocol, which is an IP-in-UDP tunneling
> protocol. Usually GTP is used in connecting between base station for
> radio, Serving Gateway (S-GW), and PDN Gateway (P-GW).
>
> This patch implements GTP-U protocol for userspace datapath,
> supporting only required header fields and G-PDU message type.
> See spec in:
> https://tools.ietf.org/html/draft-hmm-dmm-5g-uplane-analysis-00
>
> Signed-off-by: Yi Yang
> Co-authored-by: Yi Yang
> Signed-off-by: William Tu
Thanks a lot! I made another pass and noticed a few more things.
For some "flags" fields, where it's important to understand the flags,
we break out the flags for user comprehension. For example, we do this
with TCP flags. Do you have an idea whether the GTP-U flags are
important enough for this? If so, then we'd need some additional
changes for parsing and formatting GTP-U flags. If not, I suggest
changing formatting for them in meta-flow.h from "decimal" to
"hexadecimal" because it's easier to understand bit-mappings from hex to
binary in your head (my suggested patch does that).
I think that flow_get_metadata() should copy the new fields.
These new fields are marked writable. Is it actually safe to let the
user change the flags field? It seems to me that all of the bits here
are either fixed or indicate whether some following field is present, so
that changing it could break the interpretation of the packet. Maybe
the flags should be read-only.
I think that format_flow_tunnel() in lib/match.c should format the new
fields.
The use of "? :" as in netdev_gtpu_build_header() is a GCC extension. I
think that MSVC will reject it.
Doesn't tun_key_to_attr() need to support the new fields?
I'm pretty suspicious of the treatment of PT_GTPU_MSG packets. I don't
know what can be done with them. I bet they have not been tested.
I'm appending a few more minor suggestions.
Thanks again!
Ben
-8<--cut here-->8--
diff --git a/Documentation/faq/configuration.rst
b/Documentation/faq/configuration.rst
index a9ac9354d0dc..4a98740c5d4d 100644
--- a/Documentation/faq/configuration.rst
+++ b/Documentation/faq/configuration.rst
@@ -227,9 +227,9 @@ Q: Does Open vSwitch support IPv6 GRE?
Q: Does Open vSwitch support GTP-U?
-A: Yes. GTP-U (GPRS Tunnelling Protocol User Plane (GTPv1-U))
-is supported in userspace datapath. TEID is set by using tunnel
-key field.
+A: Yes. Starting with version 2.13, the Open vSwitch userspace
+datapath supports GTP-U (GPRS Tunnelling Protocol User Plane
+(GTPv1-U)). TEID is set by using tunnel key field.
::
diff --git a/include/openvswitch/meta-flow.h b/include/openvswitch/meta-flow.h
index d57a36468e19..b3457f231f9a 100644
--- a/include/openvswitch/meta-flow.h
+++ b/include/openvswitch/meta-flow.h
@@ -512,7 +512,7 @@ enum OVS_PACKED_ENUM mf_field_id {
*
* Type: u8.
* Maskable: bitwise.
- * Formatting: decimal.
+ * Formatting: hexadecimal.
* Prerequisites: none.
* Access: read/write.
* NXM: none.
diff --git a/lib/netdev-native-tnl.c b/lib/netdev-native-tnl.c
index 7ae554c87964..bbce5e1f55cb 100644
--- a/lib/netdev-native-tnl.c
+++ b/lib/netdev-native-tnl.c
@@ -738,7 +738,7 @@ netdev_gtpu_pop_header(struct dp_packet *packet)
tnl->gtpu_flags = gtph->md.flags;
tnl->gtpu_msgtype = gtph->md.msgtype;
-tnl->tun_id = htonll(ntohl(get_16aligned_be32(>teid)));
+tnl->tun_id = be32_to_be64(get_16aligned_be32(>teid));
if (tnl->gtpu_msgtype == GTPU_MSGTYPE_GPDU) {
struct ip_header *ip;
diff --git a/lib/packets.h b/lib/packets.h
index 6a4d3fb87392..405ea9325c21 100644
--- a/lib/packets.h
+++ b/lib/packets.h
@@ -1498,12 +1498,14 @@ struct gtpu_metadata {
uint8_t flags;
uint8_t msgtype;
};
+BUILD_ASSERT_DECL(sizeof(struct gtpu_metadata) == 2);
struct gtpuhdr {
struct gtpu_metadata md;
ovs_be16 len;
ovs_16aligned_be32 teid;
};
+BUILD_ASSERT_DECL(sizeof(struct gtpuhdr) == 8);
/* VXLAN protocol header */
struct vxlanhdr {
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] compiling on v5.4 kernel
On 12/5/19 5:29 PM, Gregory Rose wrote: > > On 12/5/2019 3:22 PM, Gregory Rose wrote: >> >> On 12/5/2019 2:15 PM, Ben Pfaff wrote: >>> On Thu, Dec 05, 2019 at 01:14:54PM -0800, Gregory Rose wrote: We try to keep our out of tree kernel modules compiling against recent kernels and will eventually add support for 5.4. Right now our support is up to 5.0. >>> My belief is that usually we're only 1-2 releases behind, 4 is more than >>> I usually expect. Have we been particularly pressed with other issues >>> recently? >> >> No more than usual I guess. I know my attention has definitely been >> elsewhere lately. >> >> Let me look into it and scope the effort to pull us up to 5.4. The 5.0 >> kernel isn't even >> listed at kernel.org with 4.19 being the latest LTS that we support. >> If 5.4 is going to be >> LTS as well then it makes sense to support it. > > I tried building against the 5.4.2 kernel from kernel.org and found the > inet frags issue that David pointed out > To see if there were any other problems I then I ran 'make -i' but found > nothing else. It should just be > a compat layer fixup for the inet frags issue. > > Maybe I can get a patch out for 5.4 support next week if no unforeseen > complications > arise. Hopefully that can help David out in a timely manner as well. > That would be a huge help. Thanks, Greg. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH v2 2/3] travis: Move x86-only addon packages to linux-prepare.sh
To enable multiple CPU architectures support, it is necessary to move the
x86-only addon packages from .travis.yml file. Otherwise, the x86-only
addon packages will break the builds on some other CPU architectures.
Reviewed-by: Yanqin Wei
Reviewed-by: Malvika Gupta
Reviewed-by: Gavin Hu
Reviewed-by: Ruifeng Wang
Signed-off-by: Lance Yang
---
.travis.yml | 2 --
.travis/linux-prepare.sh | 3 ++-
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/.travis.yml b/.travis.yml
index 482efd2..2dc4d43 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -14,7 +14,6 @@ addons:
apt:
packages:
- bc
- - gcc-multilib
- libssl-dev
- llvm-dev
- libjemalloc1
@@ -26,7 +25,6 @@ addons:
- libelf-dev
- selinux-policy-dev
- libunbound-dev
- - libunbound-dev:i386
- libunwind-dev
before_install: ./.travis/${TRAVIS_OS_NAME}-prepare.sh
diff --git a/.travis/linux-prepare.sh b/.travis/linux-prepare.sh
index 9e3ac0d..6421066 100755
--- a/.travis/linux-prepare.sh
+++ b/.travis/linux-prepare.sh
@@ -18,7 +18,8 @@ pip install --user --upgrade docutils
if [ "$M32" ]; then
# 32-bit and 64-bit libunwind can not be installed at the same time.
# This will remove the 64-bit libunwind and install 32-bit version.
-sudo apt-get install -y libunwind-dev:i386
+sudo apt-get install -y \
+libunwind-dev:i386 libunbound-dev:i386 gcc-multilib
fi
# IPv6 is supported by kernel but disabled in TravisCI images:
--
2.7.4
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH v2 1/3] dpif-netdev-perf: Fix using of unitialized last_tsc
When compiling Open vSwitch on aarch64, the compiler will warn about an uninitailized variable in lib/dpif-netdev-perf.c. If the clock_gettime function in rdtsc_syscall fails, the member last_tsc of the unitialized struct will be returned. In order to avoid the warnings, it is necessary to initialize the variable before using. Reviewed-by: Yanqin Wei Reviewed-by: Malvika Gupta Signed-off-by: Lance Yang --- lib/dpif-netdev-perf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/dpif-netdev-perf.c b/lib/dpif-netdev-perf.c index baf90b0..58728ab 100644 --- a/lib/dpif-netdev-perf.c +++ b/lib/dpif-netdev-perf.c @@ -76,7 +76,7 @@ pmd_perf_estimate_tsc_frequency(void) break; } } - +memset(, 0, sizeof s); start = cycles_counter_update(); /* Using xnanosleep as it's interrupt resistant. * Sleeping only 100 ms to avoid holding the main thread for too long. */ -- 2.7.4 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH v2 3/3] travis: Enable OvS Travis CI for arm
Enable part of travis jobs with gcc compiler for arm64 architecture
1. Add arm jobs into the matrix in .travis.yml configuration file
2. To enable OVS-DPDK jobs, set the build target according to
different CPU architectures
3. Temporarily disable sparse checker because of static code checking
failure on arm64
Successful travis build jobs report:
https://travis-ci.org/yzyuestc/ovs/builds/621037339
Reviewed-by: Yanqin Wei
Reviewed-by: Jieqiang Wang
Reviewed-by: Gavin Hu
Signed-off-by: Lance Yang
---
.travis.yml| 18 ++
.travis/linux-build.sh | 16 ++--
2 files changed, 32 insertions(+), 2 deletions(-)
diff --git a/.travis.yml b/.travis.yml
index 2dc4d43..f82e484 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -50,6 +50,24 @@ matrix:
- os: osx
compiler: clang
env: OPTS="--disable-ssl"
+- arch: arm64
+ compiler: gcc
+ env: OPTS="--disable-ssl"
+- arch: arm64
+ compiler: gcc
+ env: KERNEL_LIST="5.0 4.20 4.19 4.18 4.17 4.16"
+- arch: arm64
+ compiler: gcc
+ env: KERNEL_LIST="4.15 4.14 4.9 4.4 3.16"
+- arch: arm64
+ compiler: gcc
+ env: DPDK=1 OPTS="--enable-shared"
+- arch: arm64
+ compiler: gcc
+ env: DPDK_SHARED=1
+- arch: arm64
+ compiler: gcc
+ env: DPDK_SHARED=1 OPTS="--enable-shared"
script: ./.travis/${TRAVIS_OS_NAME}-build.sh $OPTS
diff --git a/.travis/linux-build.sh b/.travis/linux-build.sh
index bb47b3e..ce6bfd1 100755
--- a/.travis/linux-build.sh
+++ b/.travis/linux-build.sh
@@ -6,7 +6,7 @@ set -x
CFLAGS_FOR_OVS="-g -O2"
SPARSE_FLAGS=""
EXTRA_OPTS="--enable-Werror"
-TARGET="x86_64-native-linuxapp-gcc"
+TARGET=""
function install_kernel()
{
@@ -87,6 +87,16 @@ function install_dpdk()
local DPDK_VER=$1
local VERSION_FILE="dpdk-dir/travis-dpdk-cache-version"
+if [ -z "$TARGET" -a -z "$TRAVIS_ARCH" ] ||
+ [ "$TRAVIS_ARCH" == "amd64" ]; then
+TARGET="x86_64-native-linuxapp-gcc"
+elif [ "$TRAVIS_ARCH" == "aarch64" ]; then
+TARGET="arm64-armv8a-linuxapp-gcc"
+else
+echo "Target is unknown"
+exit 1
+fi
+
if [ "${DPDK_VER##refs/*/}" != "${DPDK_VER}" ]; then
# Avoid using cache for git tree build.
rm -rf dpdk-dir
@@ -184,7 +194,9 @@ elif [ "$M32" ]; then
# difference on 'configure' and 'make' stages.
export CC="$CC -m32"
else
-OPTS="--enable-sparse"
+if [ "$TRAVIS_ARCH" != "aarch64" ]; then
+OPTS="--enable-sparse"
+fi
if [ "$AFXDP" ]; then
# netdev-afxdp uses memset for 64M for umem initialization.
SPARSE_FLAGS="${SPARSE_FLAGS} -Wno-memcpy-max-count"
--
2.7.4
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH v2 0/3] Fix issues and enable Travis CI on arm
To enable Travis CI on arm, these patches fix some issues and modify shell scripts to support multi-arch CPU. These patches only enable part of the travis jobs for arm. The other jobs will be enabled after related issues are fixed. Regarding the patches to enable ppc64le builds on Travis CI are under review, some codes or conflicts may need to be merged after review. Changes since v1: - move the initialization code for pmd_perf_stats to an appropriate location - remove cache split scripts - merge two patches into a single one - modify commit message to describe the issue more clearly Lance Yang (3): [ovs-dev] [PATCH 1/3] dpif-netdev-perf: Fix using of unitialized last_tsc [ovs-dev] [PATCH 2/3] travis: Move x86-only addon packages to linux-prepare.sh [ovs-dev] [PATCH 3/3] travis: Enable OvS Travis CI for arm .travis.yml | 20 ++-- .travis/linux-build.sh | 16 ++-- .travis/linux-prepare.sh | 3 ++- lib/dpif-netdev-perf.c | 2 +- 4 files changed, 35 insertions(+), 6 deletions(-) -- 2.7.4 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] compiling on v5.4 kernel
On 12/5/2019 3:22 PM, Gregory Rose wrote: On 12/5/2019 2:15 PM, Ben Pfaff wrote: On Thu, Dec 05, 2019 at 01:14:54PM -0800, Gregory Rose wrote: We try to keep our out of tree kernel modules compiling against recent kernels and will eventually add support for 5.4. Right now our support is up to 5.0. My belief is that usually we're only 1-2 releases behind, 4 is more than I usually expect. Have we been particularly pressed with other issues recently? No more than usual I guess. I know my attention has definitely been elsewhere lately. Let me look into it and scope the effort to pull us up to 5.4. The 5.0 kernel isn't even listed at kernel.org with 4.19 being the latest LTS that we support. If 5.4 is going to be LTS as well then it makes sense to support it. I tried building against the 5.4.2 kernel from kernel.org and found the inet frags issue that David pointed out To see if there were any other problems I then I ran 'make -i' but found nothing else. It should just be a compat layer fixup for the inet frags issue. Maybe I can get a patch out for 5.4 support next week if no unforeseen complications arise. Hopefully that can help David out in a timely manner as well. - Greg ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] compiling on v5.4 kernel
On 12/5/2019 2:15 PM, Ben Pfaff wrote: On Thu, Dec 05, 2019 at 01:14:54PM -0800, Gregory Rose wrote: We try to keep our out of tree kernel modules compiling against recent kernels and will eventually add support for 5.4. Right now our support is up to 5.0. My belief is that usually we're only 1-2 releases behind, 4 is more than I usually expect. Have we been particularly pressed with other issues recently? No more than usual I guess. I know my attention has definitely been elsewhere lately. Let me look into it and scope the effort to pull us up to 5.4. The 5.0 kernel isn't even listed at kernel.org with 4.19 being the latest LTS that we support. If 5.4 is going to be LTS as well then it makes sense to support it. Thanks, - Greg ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] 淘宝双12~先领内部优惠券~再买买买~省钱还返佣
一句话不割~~~早上开会，又降工资，职工降百分之二十，领导降百分之三~~~真是穷谁不能穷领导，富谁不能富工人~~同意点左吧 不想再收到此类邮件，点击退订？退订邮件 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] Donation
You have a donation of 4,800,000.00 EURO, i won the America lottery worth 40 million U.S Dollars in America and decided to donate a portion of it to five lucky people and charity homes in memory of my late wife who died of cancer. Contact me for more details at: infottc...@gmail.com ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] compiling on v5.4 kernel
On Thu, Dec 05, 2019 at 01:14:54PM -0800, Gregory Rose wrote: > We try to keep our out of tree kernel modules compiling against recent > kernels and will eventually add support for 5.4. Right now our > support is up to 5.0. My belief is that usually we're only 1-2 releases behind, 4 is more than I usually expect. Have we been particularly pressed with other issues recently? ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] compiling on v5.4 kernel
On 12/5/2019 1:19 PM, David Ahern wrote: On 12/5/19 2:14 PM, Gregory Rose wrote: We try to keep our out of tree kernel modules compiling against recent kernels and will eventually add support for 5.4. Right now our support is up to 5.0. However, you can just build the user space code and not bother with building the out of tree kernel modules and then just use the built-in openvswitch kernel module for 5.4. Is there some specific need for the out of tree kernel modules to compile on 5.4 right now? sadly, it is for an out of tree module. STT. I guess I could try bringing just that one into the kernel and try a build. I guess it's worth a shot but there might be internal dependencies to the other OOT modules and that could get messy. Let me know how it goes. Meanwhile, we'll look into adding support for 5.4 but I can't commit to any timeline. Good luck! - Greg ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] compiling on v5.4 kernel
On 12/5/19 2:14 PM, Gregory Rose wrote: > > We try to keep our out of tree kernel modules compiling against recent > kernels and > will eventually add support for 5.4. Right now our support is up to > 5.0. However, > you can just build the user space code and not bother with building the > out of > tree kernel modules and then just use the built-in openvswitch kernel > module for 5.4. > > Is there some specific need for the out of tree kernel modules to > compile on 5.4 > right now? > sadly, it is for an out of tree module. STT. I guess I could try bringing just that one into the kernel and try a build. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] compiling on v5.4 kernel
On 12/5/2019 11:52 AM, David Ahern wrote: Hi: I am trying to compile ovs code from github for the 5.4 kernel and the module builds are failing (excerpt pasted below). Is anyone working on moving the out of tree modules forward to 5.4 now that it is released and targeted as an LTS? Thanks, David Hi David, We try to keep our out of tree kernel modules compiling against recent kernels and will eventually add support for 5.4. Right now our support is up to 5.0. However, you can just build the user space code and not bother with building the out of tree kernel modules and then just use the built-in openvswitch kernel module for 5.4. Is there some specific need for the out of tree kernel modules to compile on 5.4 right now? Thanks, - Greg ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCHv4] userspace: Add GTP-U support.
GTP, GPRS Tunneling Protocol, is a group of IP-based communications protocols used to carry general packet radio service (GPRS) within GSM, UMTS and LTE networks. GTP protocol has two parts: Signalling (GTP-Control, GTP-C) and User data (GTP-User, GTP-U). GTP-C is used for setting up GTP-U protocol, which is an IP-in-UDP tunneling protocol. Usually GTP is used in connecting between base station for radio, Serving Gateway (S-GW), and PDN Gateway (P-GW). This patch implements GTP-U protocol for userspace datapath, supporting only required header fields and G-PDU message type. See spec in: https://tools.ietf.org/html/draft-hmm-dmm-5g-uplane-analysis-00 Signed-off-by: Yi Yang Co-authored-by: Yi Yang Signed-off-by: William Tu --- v3 -> v4: - applied Ben's doc revise - increment FLOW_WC_SEQ to 42 - minor fixes - travis: https://travis-ci.org/williamtu/ovs-travis/builds/621289678 v2 -> v3: - pick up the code from v2, rebase to master - many fixes in code, docs, and add more tests - travis: https://travis-ci.org/williamtu/ovs-travis/builds/619799361 v1 -> v2: - Add new packet_type PT_GTPU_MSG to handle GTP-U signaling message, GTP-U signaling message should be steered into a control plane handler by explicit openflow entry in flow table. - Fix gtpu_flags and gptu_msgtype set issue. - Verify communication with kernel GTP implementation from Jiannan Ouyang. - Fix unit test issue and make sure all the unit tests can pass. - This patch series add GTP-U tunnel support in DPDK userspace, GTP-U is used for carrying user data within the GPRS core network and between the radio access network and the core network. The user data transported can be packets in any of IPv4, IPv6, or PPP formats. --- Documentation/faq/configuration.rst | 13 +++ Documentation/faq/releases.rst| 1 + NEWS | 3 + datapath/linux/compat/include/linux/openvswitch.h | 2 + include/openvswitch/flow.h| 4 +- include/openvswitch/match.h | 6 ++ include/openvswitch/meta-flow.h | 28 ++ include/openvswitch/packets.h | 4 +- lib/dpif-netlink-rtnl.c | 5 + lib/dpif-netlink.c| 5 + lib/flow.c| 22 +++-- lib/flow.h| 2 +- lib/match.c | 30 +- lib/meta-flow.c | 38 lib/meta-flow.xml | 79 ++- lib/netdev-native-tnl.c | 85 lib/netdev-native-tnl.h | 8 ++ lib/netdev-vport.c| 25 - lib/nx-match.c| 8 +- lib/odp-util.c| 114 +- lib/odp-util.h| 2 +- lib/ofp-match.c | 2 +- lib/packets.h | 59 +++ lib/tnl-ports.c | 3 + ofproto/ofproto-dpif-rid.h| 2 +- ofproto/ofproto-dpif-xlate.c | 6 +- ofproto/tunnel.c | 3 +- tests/ofproto.at | 4 +- tests/tunnel-push-pop.at | 22 + tests/tunnel.at | 78 +++ vswitchd/vswitch.xml | 24 + 31 files changed, 658 insertions(+), 29 deletions(-) diff --git a/Documentation/faq/configuration.rst b/Documentation/faq/configuration.rst index ff3b71a5d4ef..a9ac9354d0dc 100644 --- a/Documentation/faq/configuration.rst +++ b/Documentation/faq/configuration.rst @@ -225,6 +225,19 @@ Q: Does Open vSwitch support IPv6 GRE? options:remote_ip=fc00:100::1 \ options:packet_type=legacy_l2 +Q: Does Open vSwitch support GTP-U? + +A: Yes. GTP-U (GPRS Tunnelling Protocol User Plane (GTPv1-U)) +is supported in userspace datapath. TEID is set by using tunnel +key field. + +:: + +$ ovs-vsctl add-br br0 +$ ovs-vsctl add-port br0 gtpu0 -- \ +set int gtpu0 type=gtpu options:key= \ +options:remote_ip=172.31.1.1 + Q: How do I connect two bridges? A: First, why do you want to do this? Two connected bridges are not much diff --git a/Documentation/faq/releases.rst b/Documentation/faq/releases.rst index 6702c58a2b6f..4fa28a378603 100644 --- a/Documentation/faq/releases.rst +++ b/Documentation/faq/releases.rst @@ -130,6 +130,7 @@ Q: Are all features available with all datapaths? Tunnel - Geneve-IPv64.42.6 2.6 NO Tunnel - ERSPAN
[ovs-dev] compiling on v5.4 kernel
Hi: I am trying to compile ovs code from github for the 5.4 kernel and the module builds are failing (excerpt pasted below). Is anyone working on moving the out of tree modules forward to 5.4 now that it is released and targeted as an LTS? Thanks, David /home/dahern/oss/ovs.git/datapath/linux/compat/include/net/inet_frag.h: In function 'inet_frag_evicting': /home/dahern/oss/ovs.git/datapath/linux/compat/include/net/inet_frag.h:21:49: error: 'struct inet_frag_queue' has no member named 'fragments'; did you mean 'rb_fragments'? return (q_flags(q) & INET_FRAG_FIRST_IN) && q->fragments != NULL; ^ rb_fragments /home/dahern/oss/ovs.git/datapath/linux/compat/include/net/inet_frag.h: At top level: /home/dahern/oss/ovs.git/datapath/linux/compat/include/net/inet_frag.h:46:50: warning: 'struct netns_frags' declared inside parameter list will not be visible outside of this definition or declaration static inline void rpl_sub_frag_mem_limit(struct netns_frags *nf, int i) ^~~ /home/dahern/oss/ovs.git/datapath/linux/compat/include/net/inet_frag.h: In function 'rpl_sub_frag_mem_limit': /home/dahern/oss/ovs.git/datapath/linux/compat/include/net/inet_frag.h:48:19: error: dereferencing pointer to incomplete type 'struct netns_frags' atomic_sub(i, >mem); ^~ /home/dahern/oss/ovs.git/datapath/linux/compat/include/net/inet_frag.h: At top level: /home/dahern/oss/ovs.git/datapath/linux/compat/include/net/inet_frag.h:52:50: warning: 'struct netns_frags' declared inside parameter list will not be visible outside of this definition or declaration static inline void rpl_add_frag_mem_limit(struct netns_frags *nf, int i) ^~~ /home/dahern/oss/ovs.git/datapath/linux/compat/include/net/inet_frag.h: In function 'rpl_add_frag_mem_limit': /home/dahern/oss/ovs.git/datapath/linux/compat/include/net/inet_frag.h:54:19: error: dereferencing pointer to incomplete type 'struct netns_frags' atomic_add(i, >mem); ^~ ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCHv3] userspace: Add GTP-U support.
On Thu, Dec 05, 2019 at 09:26:06AM -0800, Ben Pfaff wrote: > On Thu, Dec 05, 2019 at 05:41:45AM -0800, William Tu wrote: > > One question I have in this patch is whether to increase FLOW_WC_SEQ. > > And what's the purpose of this number? > > > > /* This sequence number should be incremented whenever anything involving > > flows > >* or the wildcarding of flows changes. This will cause build assertion > >* failures in places which likely need to be updated. */ > > #define FLOW_WC_SEQ 41 > > > > In this patch, the struct flow_tnl is modified but size does not increase, > > so build assertion is passed. > > The purpose is to trigger build assertions in all the places that are > likely to require updates when a new field is added. The change in size > is just a way to trigger a reminder to update FLOW_WC_SEQ; not all new > fields change the size, but many new fields do. > > I recommend incrementing it, because the updates to the build assertions > throughout the tree also help with review. OK will do it. Thank you William ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCHv3] userspace: Add GTP-U support.
On Thu, Dec 05, 2019 at 05:41:45AM -0800, William Tu wrote: > One question I have in this patch is whether to increase FLOW_WC_SEQ. > And what's the purpose of this number? > > /* This sequence number should be incremented whenever anything involving > flows >* or the wildcarding of flows changes. This will cause build assertion >* failures in places which likely need to be updated. */ > #define FLOW_WC_SEQ 41 > > In this patch, the struct flow_tnl is modified but size does not increase, > so build assertion is passed. The purpose is to trigger build assertions in all the places that are likely to require updates when a new field is added. The change in size is just a way to trigger a reminder to update FLOW_WC_SEQ; not all new fields change the size, but many new fields do. I recommend incrementing it, because the updates to the build assertions throughout the tree also help with review. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH v2] dpif-netdev-perf: Accurate cycle counter update
The accurate timing implementation in this patch gets the wall clock counter via
cntvct_el0 register access. This call is portable to all aarch64 architectures
and has been verified on an 64-bit arm server.
Suggested-by: Yanqin Wei
Signed-off-by: Malvika Gupta
Reviewed-by: Ilya Maximets
---
v2:
- Updated patch subject to remove redundant words and enhance clarity.
- Modify code to write directly to s->last_tsc instead of writing to a local
variable first and then assigning it to s->last_tsc.
---
lib/dpif-netdev-perf.h | 4
1 file changed, 4 insertions(+)
diff --git a/lib/dpif-netdev-perf.h b/lib/dpif-netdev-perf.h
index ce369375b..72645b6b3 100644
--- a/lib/dpif-netdev-perf.h
+++ b/lib/dpif-netdev-perf.h
@@ -220,6 +220,10 @@ cycles_counter_update(struct pmd_perf_stats *s)
asm volatile("rdtsc" : "=a" (l), "=d" (h));
return s->last_tsc = ((uint64_t) h << 32) | l;
+#elif !defined(_MSC_VER) && defined(__aarch64__)
+asm volatile("mrs %0, cntvct_el0" : "=r" (s->last_tsc));
+
+return s->last_tsc;
#elif defined(__linux__)
return rdtsc_syscall(s);
#else
--
2.17.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH 15/20] netdev-offload-dpdk-flow: Support offload of output action
On Wed, Dec 4, 2019 at 8:55 PM Eli Britstein wrote:
>
>
> On 12/3/2019 5:19 PM, Sriharsha Basavapatna wrote:
> > On Wed, Nov 20, 2019 at 9:07 PM Eli Britstein wrote:
> >> Signed-off-by: Eli Britstein
> >> Reviewed-by: Oz Shlomo
> >> ---
> >> NEWS | 2 +
> >> lib/netdev-offload-dpdk-flow.c | 87
> >> --
> >> 2 files changed, 85 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/NEWS b/NEWS
> >> index 88b818948..ca9c2b230 100644
> >> --- a/NEWS
> >> +++ b/NEWS
> >> @@ -10,6 +10,8 @@ Post-v2.12.0
> >> if supported by libbpf.
> >>* Add option to enable, disable and query TCP sequence checking in
> >> conntrack.
> >> + - DPDK:
> >> + * Add hardware offload support for output actions.
> >>
> >> v2.12.0 - 03 Sep 2019
> >> -
> >> diff --git a/lib/netdev-offload-dpdk-flow.c
> >> b/lib/netdev-offload-dpdk-flow.c
> >> index dbbc45e99..6e7efb315 100644
> >> --- a/lib/netdev-offload-dpdk-flow.c
> >> +++ b/lib/netdev-offload-dpdk-flow.c
> >> @@ -274,6 +274,28 @@ ds_put_flow_action(struct ds *s, const struct
> >> rte_flow_action *actions)
> >> } else {
> >> ds_put_cstr(s, " RSS = null\n");
> >> }
> >> +} else if (actions->type == RTE_FLOW_ACTION_TYPE_COUNT) {
> >> +const struct rte_flow_action_count *count = actions->conf;
> >> +
> >> +ds_put_cstr(s, "rte flow count action:\n");
> >> +if (count) {
> >> +ds_put_format(s,
> >> + " Count: shared=%d, id=%d\n",
> >> + count->shared, count->id);
> >> +} else {
> >> +ds_put_cstr(s, " Count = null\n");
> >> +}
> >> +} else if (actions->type == RTE_FLOW_ACTION_TYPE_PORT_ID) {
> >> +const struct rte_flow_action_port_id *port_id = actions->conf;
> >> +
> >> +ds_put_cstr(s, "rte flow port-id action:\n");
> >> +if (port_id) {
> >> +ds_put_format(s,
> >> + " Port-id: original=%d, id=%d\n",
> >> + port_id->original, port_id->id);
> >> +} else {
> >> +ds_put_cstr(s, " Port-id = null\n");
> >> +}
> >> } else {
> >> ds_put_format(s, "unknown rte flow action (%d)\n",
> >> actions->type);
> >> }
> >> @@ -531,19 +553,76 @@ netdev_dpdk_flow_patterns_add(struct flow_patterns
> >> *patterns,
> >> return 0;
> >> }
> >>
> >> +static void
> >> +netdev_dpdk_flow_add_count_action(struct flow_actions *actions)
> >> +{
> >> +struct rte_flow_action_count *count = xzalloc(sizeof *count);
> >> +
> >> +count->shared = 0;
> >> +/* Each flow has a single count action, so no need of id */
> >> +count->id = 0;
> >> +add_flow_action(actions, RTE_FLOW_ACTION_TYPE_COUNT, count);
> >> +}
> >> +
> >> +static void
> >> +netdev_dpdk_flow_add_port_id_action(struct flow_actions *actions,
> >> +struct netdev *outdev)
> >> +{
> >> +struct rte_flow_action_port_id *port_id = xzalloc(sizeof *port_id);
> >> +
> >> +port_id->id = netdev_dpdk_get_port_id(outdev);
> >> +add_flow_action(actions, RTE_FLOW_ACTION_TYPE_PORT_ID, port_id);
> >> +}
> >> +
> >> +static int
> >> +netdev_dpdk_flow_add_output_action(struct flow_actions *actions,
> >> + const struct nlattr *nla,
> >> + struct offload_info *info)
> >> +{
> >> +struct netdev *outdev;
> >> +odp_port_t port;
> >> +
> >> +port = nl_attr_get_odp_port(nla);
> >> +outdev = netdev_ports_get(port, info->dpif_class);
> >> +if (outdev == NULL) {
> >> +VLOG_DBG_RL(_rl,
> >> +"Cannot find netdev for odp port %d", port);
> >> +return -1;
> >> +}
> >> +if (!netdev_dpdk_flow_api_supported(outdev)) {
> >> +VLOG_DBG_RL(_rl,
> >> +"Output to %s cannot be offloaded",
> >> +netdev_get_name(outdev));
> >> +return -1;
> >> +}
> >> +
> >> +netdev_dpdk_flow_add_count_action(actions);
> >> +netdev_dpdk_flow_add_port_id_action(actions, outdev);
> >> +netdev_close(outdev);
> >> +
> >> +return 0;
> >> +}
> >> +
> >> int
> >> netdev_dpdk_flow_actions_add(struct flow_actions *actions,
> >>struct nlattr *nl_actions,
> >>size_t nl_actions_len,
> >> - struct offload_info *info OVS_UNUSED)
> >> + struct offload_info *info)
> >> {
> >> struct nlattr *nla;
> >> size_t left;
> >>
> >> NL_ATTR_FOR_EACH_UNSAFE (nla, left, nl_actions, nl_actions_len) {
> >> -VLOG_DBG_RL(_rl,
> >> -"Unsupported action type %d", nl_attr_type(nla));
> >> -return -1;
> >> +if (nl_attr_type(nla) == OVS_ACTION_ATTR_OUTPUT &&
> >> +
Re: [ovs-dev] [PATCH 00/20] netdev datapath actions offload
On Thu, Dec 5, 2019 at 2:38 PM Eli Britstein wrote: > > > On 12/5/2019 9:55 AM, Sriharsha Basavapatna wrote: > > Hi Eli, > > > > Any reason why tnl_pop is not included in this patch set ? > > > > Thanks, > > -Harsha > > Currently offloading of vports does not work. Ilya works on that > together with Ophir. > > However, the decap process in OVS-DPDK is much more complex. It consists > of 2 flows - tnl_pop on the PF, and tunnel flow on the vport. > > So, offloading it will be not as straight forward as simple output, drop > or encap (clone) in this series. > > In HW, once we do "VXLAN_DECAP", the outer header is lost. As the outer > header is required in the vport flow, we won't be able to do the decap > in the tnl_pop flow. > > Instead it will be in the vport flow. > > Furthermore, as those are 2 different flows, we must be able to cope > with a scenario that only the tnl_pop flow exist and hit, and the vport > flow doesn't. > > In this case, we must be able to handle this HW miss, and proceed the > processing in SW. > > Those are all covered in the next series we work on, and will submit it > once the current output series is accepted. > Ok, thanks. -Harsha ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] Re. Guten Tag
Liebste Geliebte, Ich bin David Raymon. Ein portugiesischer Staatsbьrger. Ich habe gesucht und Ihre E-Mail gesehen. Also habe ich beschlossen, Ihnen zu schreiben, ob Ihre E-Mail echt ist. Bei mir wurde Speiserцhrenkrebs diagnostiziert. Es hat alle Formen der medizinischen Behandlung verunreinigt, und jetzt habe ich nur noch ein paar Monate zu leben. Ich bin sehr reich, war aber nie groЯzьgig; Ich habe den grцЯten Teil meines Vermцgens meinen unmittelbaren Familienmitgliedern gegeben. Ich habe beschlossen, Almosen an Wohltдtigkeitsorganisationen zu spenden. Ich kann das aus gesundheitlichen Grьnden nicht mehr selbst machen. Ich habe einmal Familienmitglieder gebeten, etwas Geld an Wohltдtigkeitsorganisationen zu spenden. Sie haben dies abgelehnt und das Geld behalten. Ich habe eine riesige Bareinlage von achtzehn Millionen Dollar bei einer Sicherheitsfirma in Amerika. Ich mцchte, dass Sie mir helfen, diese Kaution zu sammeln und an Wohltдtigkeitsorganisationen zu senden. Sie werden 30% dieser Mittel fьr Ihre Unterstьtzung in Anspruch nehmen. Ich mцchte Sie bitten, den Erhalt dieser E-Mail so bald wie mцglich zu bestдtigen und sie mit absoluter Vertraulichkeit und Aufrichtigkeit zu behandeln. Bitte antworten Sie aus Sicherheitsgrьnden auf meine private E-Mail-Adresse fabiano.ron5...@gmail.com David Raymon ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH ovn] system-ovn.at: check HAVE_TCPDUMP in "2 LSs IGMP" test
On Thu, Dec 5, 2019 at 11:42 AM Lorenzo Bianconi wrote: > > Do not run "2 LSs IGMP" unitest if tcpdump is not currently installed on > the machine > > Signed-off-by: Lorenzo Bianconi Thanks Lorenzo for the patch. It looks good to me. Acked-by: Dumitru Ceara > --- > tests/system-ovn.at | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/tests/system-ovn.at b/tests/system-ovn.at > index dbff58f24..bf598aec5 100644 > --- a/tests/system-ovn.at > +++ b/tests/system-ovn.at > @@ -3128,6 +3128,7 @@ OVS_TRAFFIC_VSWITCHD_STOP(["/failed to query port > patch-.*/d > AT_CLEANUP > > AT_SETUP([ovn -- 2 LSs IGMP]) > +AT_SKIP_IF([test $HAVE_TCPDUMP = no]) > AT_KEYWORDS([ovnigmp]) > > ovn_start > -- > 2.21.0 > ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCHv5] netdev-afxdp: Enable loading XDP program.
On 23 Nov 2019, at 1:26, William Tu wrote: Now netdev-afxdp always forwards all packets to userspace because it is using libbpf's default XDP program, see 'xsk_load_xdp_prog'. There are some cases when users want to keep packets in kernel instead of sending to userspace, for example, management traffic such as SSH should be processed in kernel. The patch enables loading the user-provided XDP program by $ovs-vsctl -- set int afxdp-p0 options:xdp-obj= So users can implement their filtering logic or traffic steering idea in their XDP program, and rest of the traffic passes to AF_XDP socket handled by OVS. Did a quick test (no review) and found that we run into a repeat loop with best-effort mode: 2019-12-05T14:28:05.687Z|100465|bridge|WARN|could not open network device tapVM (No such device) 2019-12-05T14:28:05.688Z|100466|netdev_afxdp|ERR|best-effort mode and xdp-obj can't be set together 2019-12-05T14:28:05.688Z|100467|netdev|WARN|eno1: could not set configuration (Invalid argument) 2019-12-05T14:28:05.688Z|100468|netdev_afxdp|INFO|eno1: Removing xdp program. 2019-12-05T14:28:05.689Z|100469|netdev_afxdp|INFO|Removed XDP program ID: 0 2019-12-05T14:28:05.691Z|100470|bridge|WARN|could not open network device tapVM (No such device) 2019-12-05T14:28:05.692Z|100471|netdev_afxdp|ERR|best-effort mode and xdp-obj can't be set together 2019-12-05T14:28:05.692Z|100472|netdev|WARN|eno1: could not set configuration (Invalid argument) 2019-12-05T14:28:05.692Z|100473|netdev_afxdp|INFO|eno1: Removing xdp program. 2019-12-05T14:28:05.693Z|100474|netdev_afxdp|INFO|Removed XDP program ID: 0 2019-12-05T14:28:05.695Z|100475|bridge|WARN|could not open network device tapVM (No such device) 2019-12-05T14:28:05.696Z|100476|netdev_afxdp|ERR|best-effort mode and xdp-obj can't be set together 2019-12-05T14:28:05.696Z|100477|netdev|WARN|eno1: could not set configuration (Invalid argument) 2019-12-05T14:28:05.696Z|100478|netdev_afxdp|INFO|eno1: Removing xdp program. 2019-12-05T14:28:05.697Z|100479|netdev_afxdp|INFO|Removed XDP program ID: 0 2019-12-05T14:28:05.699Z|100480|bridge|WARN|could not open network device tapVM (No such device) 2019-12-05T14:28:05.700Z|100481|netdev_afxdp|ERR|best-effort mode and xdp-obj can't be set together 2019-12-05T14:28:05.700Z|100482|netdev|WARN|eno1: could not set configuration (Invalid argument) 2019-12-05T14:28:05.701Z|100483|netdev_afxdp|INFO|eno1: Removing xdp program. Loop also happens when I configure a non existing object: 2019-12-05T14:31:17.562Z|311021|netdev_afxdp|ERR|Invalid xdp-obj '/root/af_xdp_kernie.o': No such file or directory. 2019-12-05T14:31:17.562Z|311022|netdev|WARN|eno1: could not set configuration (Invalid argument) 2019-12-05T14:31:17.562Z|311023|netdev_afxdp|INFO|eno1: Removing xdp program. 2019-12-05T14:31:17.562Z|311024|netdev_afxdp|INFO|Removed XDP program ID: 0 2019-12-05T14:31:17.565Z|311025|bridge|WARN|could not open network device tapVM (No such device) 2019-12-05T14:31:17.566Z|311026|netdev_afxdp|ERR|Invalid xdp-obj '/root/af_xdp_kernie.o': No such file or directory. 2019-12-05T14:31:17.566Z|311027|netdev|WARN|eno1: could not set configuration (Invalid argument) 2019-12-05T14:31:17.566Z|311028|netdev_afxdp|INFO|eno1: Removing xdp program. 2019-12-05T14:31:17.566Z|311029|netdev_afxdp|INFO|Removed XDP program ID: 0 2019-12-05T14:31:17.569Z|311030|bridge|WARN|could not open network device tapVM (No such device) 2019-12-05T14:31:17.570Z|311031|netdev_afxdp|ERR|Invalid xdp-obj '/root/af_xdp_kernie.o': No such file or directory. 2019-12-05T14:31:17.570Z|311032|netdev|WARN|eno1: could not set configuration (Invalid argument) Signed-off-by: William Tu --- v5: - rebase to master Feedbacks from Eelco: - Remove xdp-obj="__default__" case, to remove xdp-obj, use ovs-vsctl remove int options xdp-obj - Fix problem of xdp program not unloading verify by bpftool. - use xdp-obj instead of xdpobj - Limitation: xdp-obj doesn't work when using best-effort-mode because best-effort mode tried to probe mode by setting up queue, and loading xdp-obj requires knwoing mode in advance. (to support it, we might need to use the XSK_LIBBPF_FLAGS__INHIBIT_PROG_LOAD as in v3) Testing - I place two xdp binary here https://drive.google.com/open?id=1QCCdNE-5CwlKCFV6Upg9mOPnnbVkUwA5 [xdpsock_pass.o] Working one, which forwards packets to dpif-netdev [xdpsock_invalid.o] invalid one, which has no map v4: Feedbacks from Eelco. - First load the program, then configure xsk. Let API take care of xdp prog and map loading, don't set XSK_LIBBPF_FLAGS__INHIBIT_PROG_LOAD. - When loading custom xdp, need to close(prog_fd) and close(map_fd) to release the resources - make sure prog and map is unloaded by bpftool. - update doc, afxdp.rst - Tested-at: https://travis-ci.org/williamtu/ovs-travis/builds/608986781 v3: Feedbacks
Re: [ovs-dev] [PATCH] netdev-afxdp: Add delay when reconfiguring xsk.
On Wed, Dec 4, 2019 at 10:06 PM William Tu wrote:
>
> The patch works around an error when reconfigure the netdev-afxdp
> device into different modes. Currently, when OVS destroy xsk, the
> xsk_destruct() in linux kernel calls xdp_put_umem() and defers
> calling xdp_umem_release_deferred().
>
> This creates an -EBUSY error when xsk_socket__create() calls
> xsk_bind()
> xdp_umem_assign_dev()
> xdp_get_umem_from_qid()
>
> And this is because xdp_clear_umem_at_qid() is deferred so not
> clearing umem yet. The issue can be reproduced by just changing
> xdp-mode multiple times, ex:
> ovs-vsctl -- set interface afxdp-p0 \
> options:n_rxq=1 type="afxdp" options:xdp-mode=best-effort
> ovs-vsctl -- set interface afxdp-p0 \
> options:n_rxq=1 type="afxdp" options:xdp-mode=generic
>
> The patch fixes it by adding a delay, hopefully the umem has
> been properly cleanup.
>
> Signed-off-by: William Tu
> ---
> lib/netdev-afxdp.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/lib/netdev-afxdp.c b/lib/netdev-afxdp.c
> index ca2dfd005b9f..84897f1fd025 100644
> --- a/lib/netdev-afxdp.c
> +++ b/lib/netdev-afxdp.c
> @@ -661,6 +661,9 @@ netdev_afxdp_reconfigure(struct netdev *netdev)
> struct rlimit r = {RLIM_INFINITY, RLIM_INFINITY};
> int err = 0;
>
> +/* Time for umem to be released in kernel. */
> +xnanosleep(50);
> +
> ovs_mutex_lock(>mutex);
>
> if (netdev->n_rxq == dev->requested_n_rxq
> --
> 2.7.4
>
Now I think it's a bad solution. Let me work on other way
to fix it.
Regards,
William
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCHv3] userspace: Add GTP-U support.
On Wed, Dec 4, 2019 at 9:10 PM Ben Pfaff wrote:
>
> On Wed, Dec 04, 2019 at 06:37:38PM -0800, William Tu wrote:
> > On Wed, Dec 4, 2019 at 3:49 PM Ben Pfaff wrote:
> > >
> > > On Mon, Dec 02, 2019 at 02:19:29PM -0800, William Tu wrote:
> > > > GTP, GPRS Tunneling Protocol, is a group of IP-based communications
> > > > protocols used to carry general packet radio service (GPRS) within
> > > > GSM, UMTS and LTE networks. GTP protocol has two parts: Signalling
> > > > (GTP-Control, GTP-C) and User data (GTP-User, GTP-U). GTP-C is used
> > > > for setting up GTP-U protocol, which is an IP-in-UDP tunneling
> > > > protocol. Usually GTP is used in connecting between base station for
> > > > radio, Serving Gateway (S-GW), and PDN Gateway (P-GW).
> > > >
> > > > This patch implements GTP-U protocol for userspace datapath,
> > > > supporting only required header fields and G-PDU message type.
> > > > See spec in:
> > > > https://tools.ietf.org/html/draft-hmm-dmm-5g-uplane-analysis-00
> > > >
> > > > Signed-off-by: Yi Yang
> > > > Co-authored-by: Yi Yang
> > > > Signed-off-by: William Tu
> > >
> > > Seems reasonable.
> > >
> > > Is there a larger goal here or are you just interested in the protocol?
> > >
> > Hi Ben,
> >
> > People compare vSwitch features and I always see OVS doesn't
> > support GTP-U. Other vSwitches such as VPP/tungsten vrouter all
> > support it. Since we have GTP-U v2 patch a year ago, so I'm
> > thinking about finishing it.
>
> OK! That makes sense. Thanks for doing the work!
Hi Ben,
One question I have in this patch is whether to increase FLOW_WC_SEQ.
And what's the purpose of this number?
/* This sequence number should be incremented whenever anything involving flows
* or the wildcarding of flows changes. This will cause build assertion
* failures in places which likely need to be updated. */
#define FLOW_WC_SEQ 41
In this patch, the struct flow_tnl is modified but size does not increase,
so build assertion is passed.
--- a/include/openvswitch/packets.h
+++ b/include/openvswitch/packets.h
@@ -43,7 +43,9 @@ struct flow_tnl {
uint32_t erspan_idx;
uint8_t erspan_dir;
uint8_t erspan_hwid;
-uint8_t pad1[6]; /* Pad to 64 bits. */
+uint8_t gtpu_flags;
+uint8_t gtpu_msgtype;
+uint8_t pad1[4]; /* Pad to 64 bits. */
struct tun_metadata metadata;
};
Thanks
William
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v3 00/10] Add support for offloading CT datapath rules to TC
On 12/4/2019 2:26 PM, Simon Horman wrote: > On Wed, Dec 04, 2019 at 08:10:10AM +, Paul Blakey wrote: >> On 12/3/2019 6:41 PM, Simon Horman wrote: >>> On Tue, Dec 03, 2019 at 03:45:24PM +0200, Roi Dayan wrote: The following patchset introduces hardware offload of OVS connection tracking datapath rules. OVS uses ct() and recirc() (recirculation) actions and recirc_id()/ct_state() matches to support connection tracking. The datapath rules are in the form of: recirc_id(0),in_port(dev1),eth_type(0x0800),ct_state(-trk) actions:ct(),recirc(2) recirc_id(2),in_port(dev1),eth_type(0x0800),ct_state(+trk+est) actions:4 This patchset will translate ct_state() and recirc_id() matches to tc ct_state and chain matches respectively. The datapath actions ct() and recirc() will be translated to tc actions ct and goto chain respectively. The tc equivalent commands for the above rules are: $ tc filter add dev dev1 ingress \ prio 1 chain 0 proto ip \ flower tcp ct_state -trk \ action ct pipe \ action goto chain 2 $ tc filter add dev dev1 ingress \ prio 1 chain 2 proto ip \ flower tcp ct_state +trk+est \ action mirred egress redirect dev dev2 >>> Hi Roi, >>> >>> I understand that this patchset handles adding rules as described above. >>> But do we also need a patchset to enable offload of NF flowtable, >>> so conntrack entries are offloaded? >> Yes it would be added to tc, then a upcoming kernel patchset you >> describe will actually offloaded this via act ct -> nf flow table >> offload like what nft currently does. >> >> We will submitting that to linux kernel soon. > Thanks, my follow-up question is what is the run-time effect of applying > this patch-set (and all corresponding kernel patches) but not the follow-up > described above? Are flows offloaded/not-offloaded in a manner that > allows the system to work as it would (offload aside) without this > patchset? You mean if it would be just in tc (the nf flow table -> driver part doesn't exists/enabled or driver doesn't support it)? Then tc will handle the connection tracking, similar to OvS, and there should be no issues. It will just be not hardware offloaded, same as if we set the ovs tc policy to software only. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] SEO Продвижение
Гарантированное продвижение сайта в ТОП 3 vt...@mail.ru +7(904) 925-89-94 Наши направления: SEOПродвижение, Повышение трафика на сайт, Раскрутка по поисковой видимости, Продвижение по запросам, Работы по оптимизации, Техподдержка сайта. Отправить заявку Составление семантического ядра, Составление списка минус слов, Настройка таргетинга по ГЕО, времени, возрасту, Подключение системы статистики и аналитики, Работы по увеличению конверсии сайта или лендинга Отправить заявку Написание УТП для объявления, Парсинг объявлений, Размещение объявлений , Регистрация аккаунтов с переадресацией, Обход блокировок, Рандомизация текста и фото, Работа по всем городам и категориям Отправить заявку ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH v3 ovn 2/2] northd: add logical flows for dhcpv6 pfd parsing
Introduce logical flows in ovn router pipeline in order to parse dhcpv6
advertise/reply from IPv6 prefix delegation router.
Do not overwrite ipv6_ra_pd_list info in options column of SB port_binding
table written by ovn-controller
Signed-off-by: Lorenzo Bianconi
---
northd/ovn-northd.c | 69 +++-
ovn-nb.xml | 17 +++
tests/atlocal.in| 5 +-
tests/system-ovn.at | 109
4 files changed, 198 insertions(+), 2 deletions(-)
diff --git a/northd/ovn-northd.c b/northd/ovn-northd.c
index f0847d81e..8c50218ee 100644
--- a/northd/ovn-northd.c
+++ b/northd/ovn-northd.c
@@ -2644,6 +2644,8 @@ ovn_port_update_sbrec(struct northd_context *ctx,
struct sset *active_ha_chassis_grps)
{
sbrec_port_binding_set_datapath(op->sb, op->od->sb);
+const char *ipv6_pd_list = NULL;
+
if (op->nbrp) {
/* If the router is for l3 gateway, it resides on a chassis
* and its port type is "l3gateway". */
@@ -2766,6 +2768,12 @@ ovn_port_update_sbrec(struct northd_context *ctx,
smap_add(, "l3gateway-chassis", chassis_name);
}
}
+
+ipv6_pd_list = smap_get(>sb->options, "ipv6_ra_pd_list");
+if (ipv6_pd_list) {
+smap_add(, "ipv6_ra_pd_list", ipv6_pd_list);
+}
+
sbrec_port_binding_set_options(op->sb, );
smap_destroy();
@@ -2815,6 +2823,12 @@ ovn_port_update_sbrec(struct northd_context *ctx,
smap_add_format(,
"qdisc_queue_id", "%d", queue_id);
}
+
+ipv6_pd_list = smap_get(>sb->options, "ipv6_ra_pd_list");
+if (ipv6_pd_list) {
+smap_add(, "ipv6_ra_pd_list", ipv6_pd_list);
+}
+
sbrec_port_binding_set_options(op->sb, );
smap_destroy();
if (ovn_is_known_nb_lsp_type(op->nbsp->type)) {
@@ -2864,6 +2878,12 @@ ovn_port_update_sbrec(struct northd_context *ctx,
if (chassis) {
smap_add(, "l3gateway-chassis", chassis);
}
+
+ipv6_pd_list = smap_get(>sb->options, "ipv6_ra_pd_list");
+if (ipv6_pd_list) {
+smap_add(, "ipv6_ra_pd_list", ipv6_pd_list);
+}
+
sbrec_port_binding_set_options(op->sb, );
smap_destroy();
} else {
@@ -7833,7 +7853,36 @@ build_lrouter_flows(struct hmap *datapaths, struct hmap
*ports,
free(snat_ips);
}
-/* Logical router ingress table 3: IP Input for IPv6. */
+/* DHCPv6 reply handling */
+HMAP_FOR_EACH (op, key_node, ports) {
+if (!op->nbrp) {
+continue;
+}
+
+if (op->derived) {
+continue;
+}
+
+struct lport_addresses lrp_networks;
+if (!extract_lrp_networks(op->nbrp, _networks)) {
+continue;
+}
+
+for (size_t i = 0; i < lrp_networks.n_ipv6_addrs; i++) {
+ds_clear();
+ds_clear();
+ds_put_format(, "ip6.dst == %s && udp.src == 547 &&"
+ " udp.dst == 546",
+ lrp_networks.ipv6_addrs[i].addr_s);
+ds_put_format(, "reg0 = 0; handle_dhcpv6_reply { "
+ "eth.dst <-> eth.src; ip6.dst <-> ip6.src; "
+ "outport <-> inport; output; };");
+ovn_lflow_add(lflows, op->od, S_ROUTER_IN_IP_INPUT, 100,
+ ds_cstr(), ds_cstr());
+}
+}
+
+/* Logical router ingress table 1: IP Input for IPv6. */
HMAP_FOR_EACH (op, key_node, ports) {
if (!op->nbrp) {
continue;
@@ -8634,6 +8683,24 @@ build_lrouter_flows(struct hmap *datapaths, struct hmap
*ports,
continue;
}
+struct smap options;
+/* enable IPv6 prefix delegation */
+bool prefix_delegation = smap_get_bool(>nbrp->options,
+ "prefix_delegation", false);
+if (prefix_delegation) {
+smap_clone(, >sb->options);
+smap_add(, "ipv6_prefix_delegation", "true");
+sbrec_port_binding_set_options(op->sb, );
+smap_destroy();
+}
+
+if (smap_get_bool(>nbrp->options, "prefix", false)) {
+smap_clone(, >sb->options);
+smap_add(, "ipv6_prefix", "true");
+sbrec_port_binding_set_options(op->sb, );
+smap_destroy();
+}
+
const char *address_mode = smap_get(
>nbrp->ipv6_ra_configs, "address_mode");
diff --git a/ovn-nb.xml b/ovn-nb.xml
index 5ae52bbde..d7fddcae2 100644
--- a/ovn-nb.xml
+++ b/ovn-nb.xml
@@ -2142,6 +2142,23 @@
to true.
+
+
+
+ If set to true, enable IPv6 prefix delegation state
+ machine on this logical router port
[ovs-dev] [PATCH v3 ovn 1/2] controller: add ipv6 prefix delegation state machine
Introduce IPv6 Prefix delegation state machine according to RFC 3633
https://tools.ietf.org/html/rfc3633.
Add handle_dhcpv6_reply controller action to parse advertise/reply from
IPv6 delegation server. Advertise/reply are parsed running respectively:
- pinctrl_parse_dhcv6_advt
- pinctrl_parse_dhcv6_reply
The IPv6 requesting router starts sending dhcpv6 solicit through the logical
router port marked with ipv6_prefix_delegation set to true.
An IPv6 prefix will be requested for each logical router port marked
with "prefix" set to true in option column of logical router port table.
Save IPv6 prefix received by IPv6 delegation router in the options columns of
SB port binding table in order to be reused by Router Advertisement framework
run by ovn logical router pipeline.
IPv6 Prefix delegation state machine is enabled on Gateway Router or on
a Gateway Router Port
Signed-off-by: Lorenzo Bianconi
---
controller/pinctrl.c | 607 ++
include/ovn/actions.h | 8 +-
lib/actions.c | 22 ++
lib/ovn-l7.h | 19 ++
ovn-sb.xml| 8 +
tests/ovn.at | 6 +
utilities/ovn-trace.c | 3 +
7 files changed, 672 insertions(+), 1 deletion(-)
diff --git a/controller/pinctrl.c b/controller/pinctrl.c
index c886b21d9..0ef3aef31 100644
--- a/controller/pinctrl.c
+++ b/controller/pinctrl.c
@@ -270,6 +270,19 @@ static void pinctrl_ip_mcast_handle_igmp(
const struct match *md,
struct ofpbuf *userdata);
+static void init_ipv6_prefixd(void);
+static void destroy_ipv6_prefixd(void);
+static void ipv6_prefixd_wait(long long int timeout);
+static void
+prepare_ipv6_prefix_req(struct ovsdb_idl_index *sbrec_port_binding_by_datapath,
+struct ovsdb_idl_index *sbrec_port_binding_by_name,
+const struct hmap *local_datapaths,
+const struct sbrec_chassis *chassis,
+const struct sset *active_tunnels)
+OVS_REQUIRES(pinctrl_mutex);
+static void
+send_ipv6_prefix_msg(struct rconn *swconn, long long int *send_prefixd_time)
+OVS_REQUIRES(pinctrl_mutex);
static bool may_inject_pkts(void);
static void init_put_vport_bindings(void);
@@ -457,6 +470,7 @@ pinctrl_init(void)
init_put_mac_bindings();
init_send_garps_rarps();
init_ipv6_ras();
+init_ipv6_prefixd();
init_buffered_packets_map();
init_event_table();
ip_mcast_snoop_init();
@@ -544,6 +558,57 @@ set_actions_and_enqueue_msg(struct rconn *swconn,
ofpbuf_uninit();
}
+static struct shash ipv6_prefixd;
+
+enum {
+PREFIX_SOLICIT,
+PREFIX_PENDING,
+PREFIX_DONE,
+};
+
+struct ipv6_prefixd_state {
+long long int next_announce;
+struct in6_addr ipv6_addr;
+struct eth_addr ea;
+struct eth_addr cmac;
+int64_t port_key;
+int64_t metadata;
+struct in6_addr prefix;
+unsigned plife_time;
+unsigned vlife_time;
+unsigned aid;
+unsigned t1;
+unsigned t2;
+int8_t plen;
+int state;
+};
+
+static void
+init_ipv6_prefixd(void)
+{
+shash_init(_prefixd);
+}
+
+static void
+ipv6_prefixd_delete(struct ipv6_prefixd_state *pfd)
+{
+if (pfd) {
+free(pfd);
+}
+}
+
+static void
+destroy_ipv6_prefixd(void)
+{
+struct shash_node *iter, *next;
+SHASH_FOR_EACH_SAFE (iter, next, _prefixd) {
+struct ipv6_prefixd_state *pfd = iter->data;
+ipv6_prefixd_delete(pfd);
+shash_delete(_prefixd, iter);
+}
+shash_destroy(_prefixd);
+}
+
struct buffer_info {
struct ofpbuf ofpacts;
struct dp_packet *p;
@@ -967,6 +1032,254 @@ pinctrl_handle_tcp_reset(struct rconn *swconn, const
struct flow *ip_flow,
dp_packet_uninit();
}
+static void
+pinctrl_parse_dhcv6_advt(struct rconn *swconn, const struct flow *ip_flow,
+ struct dp_packet *pkt_in, const struct match *md,
+ struct ofpbuf *userdata)
+{
+struct udp_header *udp_in = dp_packet_l4(pkt_in);
+unsigned char *in_dhcpv6_data = (unsigned char *)(udp_in + 1);
+size_t dlen = MIN(ntohs(udp_in->udp_len), dp_packet_l4_size(pkt_in));
+uint8_t *data, *end = (uint8_t *)udp_in + dlen;
+int len = 0;
+
+data = xmalloc(dlen);
+if (!data) {
+return;
+}
+
+in_dhcpv6_data += 4;
+
+while (in_dhcpv6_data < end) {
+struct dhcpv6_opt_header *in_opt =
+ (struct dhcpv6_opt_header *)in_dhcpv6_data;
+int opt_len = sizeof *in_opt + ntohs(in_opt->len);
+
+if (dlen < opt_len + len) {
+goto out;
+}
+
+switch (ntohs(in_opt->code)) {
+case DHCPV6_OPT_IA_PD: {
+int orig_len = len, hdr_len = 0, size = sizeof *in_opt + 12;
+
+memcpy([len], in_opt, size);
+in_opt = (struct dhcpv6_opt_header *)(in_dhcpv6_data + size);
+len += size;
+
+while (size < opt_len) {
+int flen = sizeof *in_opt + ntohs(in_opt->len);
+
+
[ovs-dev] [PATCH v3 ovn 0/2] Add IPv6 Prefix delegation (RFC3633)
Introduce IPv6 Prefix delegation state machine according to RFC 3633 https://tools.ietf.org/html/rfc3633. Add handle_dhcpv6_reply controller action to parse advertise/reply from IPv6 delegation server. Introduce logical flows in ovn router pipeline in order to parse dhcpv6 advertise/reply from IPv6 prefix delegation router. This series relies on the following OVS commit: https://github.com/openvswitch/ovs/commit/cec89046f72cb044b068ba6a4e30dbcc4292c4c1 Changes since v2: - add unitest support in system-ovn.at Changes since v1: - rebase on top of ovn master branch - request an IPv6 prefix for each 'downstream' logical router port marked with prefix set to true - add missing documentation - rename dhcp6_server_pkt in handle_dhcpv6_reply Lorenzo Bianconi (2): controller: add ipv6 prefix delegation state machine northd: add logical flows for dhcpv6 pfd parsing controller/pinctrl.c | 607 ++ include/ovn/actions.h | 8 +- lib/actions.c | 22 ++ lib/ovn-l7.h | 19 ++ northd/ovn-northd.c | 69 - ovn-nb.xml| 17 ++ ovn-sb.xml| 8 + tests/atlocal.in | 5 +- tests/ovn.at | 6 + tests/system-ovn.at | 109 utilities/ovn-trace.c | 3 + 11 files changed, 870 insertions(+), 3 deletions(-) -- 2.21.0 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH ovn] system-ovn.at: check HAVE_TCPDUMP in "2 LSs IGMP" test
Do not run "2 LSs IGMP" unitest if tcpdump is not currently installed on the machine Signed-off-by: Lorenzo Bianconi --- tests/system-ovn.at | 1 + 1 file changed, 1 insertion(+) diff --git a/tests/system-ovn.at b/tests/system-ovn.at index dbff58f24..bf598aec5 100644 --- a/tests/system-ovn.at +++ b/tests/system-ovn.at @@ -3128,6 +3128,7 @@ OVS_TRAFFIC_VSWITCHD_STOP(["/failed to query port patch-.*/d AT_CLEANUP AT_SETUP([ovn -- 2 LSs IGMP]) +AT_SKIP_IF([test $HAVE_TCPDUMP = no]) AT_KEYWORDS([ovnigmp]) ovn_start -- 2.21.0 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v2 1/1] dpdk: Update to use DPDK 19.11.
On 12/5/2019 8:50 AM, David Marchand wrote: On Wed, Dec 4, 2019 at 10:29 PM Stokes, Ian wrote: Thanks to all for helping with patches, reviewing and testing this series throughout the year. It's definitely made the process of upgrading DPDK easier. I've pushed this to master as we seem to have the critical numbers of acks and reviews. Thanks Ian! Should dpdk-latest be realigned to master? There is no pressure on this anyway, we can work on master atm. Yes, good point, I'll rebase and push. Regards Ian ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH 00/20] netdev datapath actions offload
On 12/5/2019 9:55 AM, Sriharsha Basavapatna wrote: > Hi Eli, > > Any reason why tnl_pop is not included in this patch set ? > > Thanks, > -Harsha Currently offloading of vports does not work. Ilya works on that together with Ophir. However, the decap process in OVS-DPDK is much more complex. It consists of 2 flows - tnl_pop on the PF, and tunnel flow on the vport. So, offloading it will be not as straight forward as simple output, drop or encap (clone) in this series. In HW, once we do "VXLAN_DECAP", the outer header is lost. As the outer header is required in the vport flow, we won't be able to do the decap in the tnl_pop flow. Instead it will be in the vport flow. Furthermore, as those are 2 different flows, we must be able to cope with a scenario that only the tnl_pop flow exist and hit, and the vport flow doesn't. In this case, we must be able to handle this HW miss, and proceed the processing in SW. Those are all covered in the next series we work on, and will submit it once the current output series is accepted. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v2 1/1] dpdk: Update to use DPDK 19.11.
On Wed, Dec 4, 2019 at 10:29 PM Stokes, Ian wrote: > Thanks to all for helping with patches, reviewing and testing this > series throughout the year. It's definitely made the process of > upgrading DPDK easier. > > I've pushed this to master as we seem to have the critical numbers of > acks and reviews. Thanks Ian! Should dpdk-latest be realigned to master? There is no pressure on this anyway, we can work on master atm. -- David Marchand ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] Congratulation
Address: Ring Rd E, Accra Hours: Closed · Opens 7:30AM Phone: 30 221 5665 Attention: Congratulation! United Nations has approved Two Million Dollars ($2m) for you as part of you compensation Please for more details get back to us for more details and direction to paying bank in West Africa Ghana. Thanks Antуnio Guterres Un Secretary General ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH ovn v8] ovn-controller: Fix use of dangling pointers in I-P runtime_data.
On Wed, Dec 4, 2019 at 10:27 PM Han Zhou wrote:
>
>
>
> On Wed, Dec 4, 2019 at 8:28 AM Dumitru Ceara wrote:
> >
> > The incremental processing engine might stop a run before the
> > en_runtime_data node is processed. In such cases the ed_runtime_data
> > fields might contain pointers to already deleted SB records. For
> > example, if a port binding corresponding to a patch port is removed from
> > the SB database and the incremental processing engine aborts before the
> > en_runtime_data node is processed then the corresponding local_datapath
> > hashtable entry in ed_runtime_data is stale and will store a pointer to
> > the already freed sbrec_port_binding record.
> >
> > This will cause invalid memory accesses in various places (e.g.,
> > pinctrl_run() -> prepare_ipv6_ras()).
> >
> > To fix the issue we introduce the engine_get_data() API which must be
> > called in order to safely access internal node data. If the node is in
> > state EN_STALE or EN_ABORTED, engine_get_data() returns NULL as the
> > references might be stale.
> >
> > This commit also adds an "is_valid()" method to engine nodes to allow
> > users to override the default behavior of determining if data is valid in a
> > node (e.g., for the ct-zones node the data is always safe to access).
> >
> > Also, all interactions with node data outside inc-proc-eng.c are now
> > performed through APIs and never by directly accessing the node->data
> > field. This makes it easier to ensure that we don't access invalid
> > (stale) data.
> >
> > CC: Han Zhou
> > Fixes: ca278d98a4f5 ("ovn-controller: Initial use of incremental engine -
> > quiet mode.")
> > Signed-off-by: Dumitru Ceara
> >
> > ---
> > v8:
> > - First two patches were applied to master, so resending the last patch
> > in the series as standalone patch.
> > - Address Han's comments:
> > - Remove internal_data from engine_node.
> > - Use the newly added engine_get_data() to make sure we access valid
> > data outside the incremental processing engine.
> > - Remove data storage outside the nodes and have the init()
> > callbacks allocate and initialize required memory.
> > - Also, for better data encapsulations:
> > - Remove all references of engine_node->data from ovn-controller.c
> > and use inc-proc-eng APIs to access the data.
> > - Change all init/cleanup/run/change_handlers to use data supplied
> > as argument.
> > - Use the newly added engine_get_input_data api to access input node
> > data.
> > - At init time, use engine_get_internal_data() to initialize the
> > callback arguments for the unix cmd handlers and to initialize
> > ofctrl.
> > ---
> > controller/ovn-controller.c | 457
> > +++-
> > lib/inc-proc-eng.c | 59 +-
> > lib/inc-proc-eng.h | 115 ---
> > 3 files changed, 370 insertions(+), 261 deletions(-)
> >
> > diff --git a/controller/ovn-controller.c b/controller/ovn-controller.c
> > index 64c44c9..5874776 100644
> > --- a/controller/ovn-controller.c
> > +++ b/controller/ovn-controller.c
> > @@ -739,26 +739,25 @@ struct ed_type_ofctrl_is_connected {
> > bool connected;
> > };
> >
> > -static void
> > -en_ofctrl_is_connected_init(struct engine_node *node)
> > +static void *
> > +en_ofctrl_is_connected_init(struct engine_node *node OVS_UNUSED,
> > +struct engine_arg *arg OVS_UNUSED)
> > {
> > -struct ed_type_ofctrl_is_connected *data =
> > -(struct ed_type_ofctrl_is_connected *)node->data;
> > -data->connected = false;
> > +struct ed_type_ofctrl_is_connected *data = xzalloc(sizeof *data);
> > +return data;
> > }
> >
> > static void
> > -en_ofctrl_is_connected_cleanup(struct engine_node *node OVS_UNUSED)
> > +en_ofctrl_is_connected_cleanup(void *data OVS_UNUSED)
> > {
> > }
> >
> > static void
> > -en_ofctrl_is_connected_run(struct engine_node *node)
> > +en_ofctrl_is_connected_run(struct engine_node *node, void *data)
> > {
> > -struct ed_type_ofctrl_is_connected *data =
> > -(struct ed_type_ofctrl_is_connected *)node->data;
> > -if (data->connected != ofctrl_is_connected()) {
> > -data->connected = !data->connected;
> > +struct ed_type_ofctrl_is_connected *of_data = data;
> > +if (of_data->connected != ofctrl_is_connected()) {
> > +of_data->connected = !of_data->connected;
> > engine_set_node_state(node, EN_UPDATED);
> > return;
> > }
> > @@ -773,21 +772,24 @@ struct ed_type_addr_sets {
> > struct sset updated;
> > };
> >
> > -static void
> > -en_addr_sets_init(struct engine_node *node)
> > +static void *
> > +en_addr_sets_init(struct engine_node *node OVS_UNUSED,
> > + struct engine_arg *arg OVS_UNUSED)
> > {
> > -struct ed_type_addr_sets *as = (struct ed_type_addr_sets *)node->data;
> > +struct ed_type_addr_sets *as = xzalloc(sizeof *as);
> > +
> >
