Re: [iovisor-dev] Unexpectedly high latencies are showed by self-written script (bpf_ktime_get_ns issue?)
On Mon, Nov 26, 2018 at 4:29 AM Aleksei Zakharov wrote:
>
> Hi, everyone!
> I've written a small script using bcc python lib for qemu block io latency
> tracing.
> I attach two uprobes to block_acct_start and block_acct_done.
>
> On some servers i can see unexpectedly high latencies:
> ~# ./qemuioslower 4
> Tracing for qemu I/O... Ctrl-C to end
> TIME LATENCYSIZE(KB) IO TYPE
> 0.018446744073709551 8192 write
> 9.7294584 18446744073709551 0 flush
> 24.815983 18446744073709551 4096 write
> 25.422378 18446744073709551 0 flush
>
> For me it looks like bpf_ktime_get_ns in stop() function returned time that
> is less, than bpf_ktime_get_ns() in start(), but why does this happen?
> May someone help me with understanding this behavior?
Maybe you want to check with bcc issue
https://github.com/iovisor/bcc/issues/728.
Basically there is a kernel bug related to bpf_ktime_get_ns() and it
is fixed in 4.9. Not sure about your kernel version.
>
> BPF code:
> #include
> BPF_HASH(req, u64);
> enum BlockAcctType {
> BLOCK_ACCT_READ,
> BLOCK_ACCT_WRITE,
> BLOCK_ACCT_FLUSH,
> BLOCK_MAX_IOTYPE,
> };
> struct data_t {
> u64 ts;
> u64 lat;
> u64 bytes;
> enum BlockAcctType type;
> };
> typedef struct BlockAcctCookie {
> int64_t bytes;
> int64_t start_time_ns;
> enum BlockAcctType type;
> } BlockAcctCookie;
> BPF_PERF_OUTPUT(events);
>
> void start(struct pt_regs *ctx) {
> u32 pid = bpf_get_current_pid_tgid();
> if (FILTER_PID)
> return;
> u64 key = 0;
> bpf_probe_read(&key, sizeof(key), (void *)PT_REGS_PARM1(ctx));
> u64 ts = bpf_ktime_get_ns();
> req.update(&key, &ts);
> }
>
> void stop(struct pt_regs *ctx,void *first, struct BlockAcctCookie *cookie) {
> struct data_t data = {};
> u64 key = 0;
> bpf_probe_read(&key, sizeof(key), (void *)PT_REGS_PARM1(ctx));
> data.ts = bpf_ktime_get_ns();
> data.type = cookie->type;
> data.bytes = cookie->bytes;
> u64 *s_time = req.lookup(&key);
> if (s_time != 0) {
> data.lat = (data.ts - *s_time);
> data.lat /= 1000;
> if (data.lat > MIN_US) {
> events.perf_submit(ctx, &data, sizeof(data));
> }
> req.delete(&key);
> }
> }
>
> Kernel: Linux hostname 4.15.0-36-generic #39~16.04.1-Ubuntu SMP Tue Sep 25
> 08:59:23 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
> bcc packages versions:
> bcc-tools 0.7.0-1
> libbcc0.7.0-1
> libcc1-0:amd645.4.0-6ubuntu1~16.04.10
> python-bcc0.7.0-1
>
>
> --
> Regards,
> Aleksei Zakharov
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1538): https://lists.iovisor.org/g/iovisor-dev/message/1538
Mute This Topic: https://lists.iovisor.org/mt/28320360/21656
Group Owner: iovisor-dev+ow...@lists.iovisor.org
Unsubscribe: https://lists.iovisor.org/g/iovisor-dev/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [iovisor-dev] question about per_cpu maps
On 11/28/18 1:50 PM, Pablo Alvarez via Lists.Iovisor.Org wrote: Dear eBPF community If I understand correctly, per_cpu maps are meant to avoid threading issues, and for example the need to call BPF_XADD to keep counters safe. There is something I am unclear about: - Is it possible for a BPF program to be preempted by another BPF program on the same CPU? eBPF programs are never preempted by the kernel, this allows to keep counters in per_cpu maps without need to use synchronized primitives on them. This is also guaranteed that there is not preemption in a chain of tail calls, then per_cpu maps can also be used to store "global variables". If this is the case, it seems that the following scenario could arise: BPF program 1 on cpu 0 reads a counter and is preempted before incrementing it BPF program 2 on cpu 0 reads the same counter, increments it, and finishes BPF program 1 on cpu 0 increments the counter At which point both programs would have read the same value for the counter, with possible problems ensuing. Is this a valid scenario? Am I missing something about how the per_cpu maps are intended to be used? Thanks Pablo Alvarez -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1537): https://lists.iovisor.org/g/iovisor-dev/message/1537 Mute This Topic: https://lists.iovisor.org/mt/28471975/21656 Group Owner: iovisor-dev+ow...@lists.iovisor.org Unsubscribe: https://lists.iovisor.org/g/iovisor-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[iovisor-dev] [PATCHv3 RFC 1/3] netdev-afxdp: add new netdev type for AF_XDP
The patch creates a new netdev type called "afxdp" and re-uses some of the
AF_XDP API implementation from xdpsock_user.c at linux sample code.
By default, it binds a device's queue 0 and uses the generic XDP support
to send and receive packets.
Signed-off-by: William Tu
---
acinclude.m4 | 13 +
configure.ac | 1 +
lib/automake.mk | 6 +-
lib/dp-packet.c | 20 ++
lib/dp-packet.h | 29 ++-
lib/netdev-afxdp.c| 703 ++
lib/netdev-afxdp.h| 41 +++
lib/netdev-linux.c| 72 +-
lib/netdev-provider.h | 1 +
lib/netdev.c | 1 +
lib/xdpsock.c | 171
lib/xdpsock.h | 144 +++
12 files changed, 1197 insertions(+), 5 deletions(-)
create mode 100644 lib/netdev-afxdp.c
create mode 100644 lib/netdev-afxdp.h
create mode 100644 lib/xdpsock.c
create mode 100644 lib/xdpsock.h
diff --git a/acinclude.m4 b/acinclude.m4
index ed83df43df54..d89d9b7d1295 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -205,6 +205,19 @@ AC_DEFUN([OVS_CHECK_LINUX_TC], [
[Define to 1 if TCA_PEDIT_KEY_EX_HDR_TYPE_UDP is available.])])
])
+dnl OVS_CHECK_LINUX_AF_XDP
+dnl
+dnl Configure Linux AF_XDP compat.
+AC_DEFUN([OVS_CHECK_LINUX_AF_XDP],
+ [AC_CHECK_HEADER([linux/if_xdp.h],
+ [HAVE_AF_XDP=yes],
+ [HAVE_AF_XDP=no])
+ AM_CONDITIONAL([HAVE_AF_XDP], [test "$HAVE_AF_XDP" = yes])
+ if test "$HAVE_AF_XDP" = yes; then
+ AC_DEFINE([HAVE_AF_XDP], [1],
+[Define to 1 if linux/if_xdp.h is available.])
+ fi])
+
dnl OVS_CHECK_DPDK
dnl
dnl Configure DPDK source tree
diff --git a/configure.ac b/configure.ac
index 3e97a750c812..0c86dae192df 100644
--- a/configure.ac
+++ b/configure.ac
@@ -136,6 +136,7 @@ OVS_LIBTOOL_VERSIONS
OVS_CHECK_CXX
AX_FUNC_POSIX_MEMALIGN
OVS_CHECK_UNBOUND
+OVS_CHECK_LINUX_AF_XDP
OVS_CHECK_INCLUDE_NEXT([stdio.h string.h])
AC_CONFIG_FILES([
diff --git a/lib/automake.mk b/lib/automake.mk
index 63e9d72ac18a..3516c0784136 100644
--- a/lib/automake.mk
+++ b/lib/automake.mk
@@ -323,7 +323,11 @@ lib_libopenvswitch_la_SOURCES = \
lib/lldp/lldpd.c \
lib/lldp/lldpd.h \
lib/lldp/lldpd-structs.c \
- lib/lldp/lldpd-structs.h
+ lib/lldp/lldpd-structs.h \
+ lib/xdpsock.c \
+ lib/xdpsock.h \
+ lib/netdev-afxdp.c \
+ lib/netdev-afxdp.h
if WIN32
lib_libopenvswitch_la_SOURCES += \
diff --git a/lib/dp-packet.c b/lib/dp-packet.c
index 93b0e9c84793..b208922945a4 100644
--- a/lib/dp-packet.c
+++ b/lib/dp-packet.c
@@ -121,6 +121,13 @@ dp_packet_uninit(struct dp_packet *b)
* created as a dp_packet */
free_dpdk_buf((struct dp_packet*) b);
#endif
+} else if (b->source == DPBUF_AFXDP) {
+struct dp_packet_afxdp *xpacket;
+
+xpacket = dp_packet_cast_afxdp(b);
+if (xpacket->mpool)
+umem_elem_push(xpacket->mpool, dp_packet_base(b));
+return;
}
}
}
@@ -249,6 +256,18 @@ dp_packet_resize__(struct dp_packet *b, size_t
new_headroom, size_t new_tailroom
case DPBUF_STACK:
OVS_NOT_REACHED();
+case DPBUF_AFXDP:
+if (new_headroom == dp_packet_headroom(b)) {
+new_base = xmalloc(new_allocated);
+} else {
+new_base = xmalloc(new_allocated);
+dp_packet_copy__(b, new_base, new_headroom, new_tailroom);
+free(dp_packet_base(b));
+}
+b->source = DPBUF_MALLOC;
+// put back to freelist
+OVS_NOT_REACHED();
+break;
case DPBUF_STUB:
b->source = DPBUF_MALLOC;
new_base = xmalloc(new_allocated);
@@ -434,6 +453,7 @@ dp_packet_steal_data(struct dp_packet *b)
{
void *p;
ovs_assert(b->source != DPBUF_DPDK);
+ovs_assert(b->source != DPBUF_AFXDP);
if (b->source == DPBUF_MALLOC && dp_packet_data(b) == dp_packet_base(b)) {
p = dp_packet_data(b);
diff --git a/lib/dp-packet.h b/lib/dp-packet.h
index 7b85dd902cce..c115c62f4c37 100644
--- a/lib/dp-packet.h
+++ b/lib/dp-packet.h
@@ -30,6 +30,7 @@
#include "packets.h"
#include "util.h"
#include "flow.h"
+#include "xdpsock.h"
#ifdef __cplusplus
extern "C" {
@@ -42,10 +43,10 @@ enum OVS_PACKED_ENUM dp_packet_source {
DPBUF_DPDK,/* buffer data is from DPDK allocated memory.
* ref to dp_packet_init_dpdk() in dp-packet.c.
*/
+DPBUF_AFXDP,
};
#define DP_PACKET_CONTEXT_SIZE 64
-
/* Buffer for holding packet data. A dp_packet is automatically reallocated
* as necessary if it grows too large for the available memory.
* By default the packet type is set to Ethernet (PT_ETH).
@@ -80,6 +81,17 @@ struct dp_packet {
};
};
+struct dp_packet_afxdp {
+struct umem_pool *mpool;
+struct dp_packet packet;
+};
+
+static struct dp_packet_afxdp *dp_packet_cast_af
[iovisor-dev] [PATCHv3 RFC 2/3] tests: add AF_XDP netdev test cases.
The patch adds the test framework for OVS using afxdp. Most of the test cases are slightly modified from the existing test cases at system-traffic.at. All the veth creations, ADD_VETH, are replaced by using AF_XDP veth, with new macro ADD_VETH_AFXDP. So packet I/O is based on AF_XDP socket interface. Signed-off-by: William Tu --- tests/automake.mk | 17 + tests/system-afxdp-macros.at| 153 tests/system-afxdp-testsuite.at | 26 + tests/system-afxdp-traffic.at | 1541 +++ 4 files changed, 1737 insertions(+) create mode 100644 tests/system-afxdp-macros.at create mode 100644 tests/system-afxdp-testsuite.at create mode 100644 tests/system-afxdp-traffic.at diff --git a/tests/automake.mk b/tests/automake.mk index 97312cf2ce6e..38cfb7158167 100644 --- a/tests/automake.mk +++ b/tests/automake.mk @@ -4,11 +4,13 @@ EXTRA_DIST += \ $(SYSTEM_TESTSUITE_AT) \ $(SYSTEM_KMOD_TESTSUITE_AT) \ $(SYSTEM_USERSPACE_TESTSUITE_AT) \ + $(SYSTEM_AFXDP_TESTSUITE_AT) \ $(SYSTEM_OFFLOADS_TESTSUITE_AT) \ $(SYSTEM_DPDK_TESTSUITE_AT) \ $(TESTSUITE) \ $(SYSTEM_KMOD_TESTSUITE) \ $(SYSTEM_USERSPACE_TESTSUITE) \ + $(SYSTEM_AFXDP_TESTSUITE) \ $(SYSTEM_OFFLOADS_TESTSUITE) \ $(SYSTEM_DPDK_TESTSUITE) \ tests/atlocal.in \ @@ -152,6 +154,11 @@ SYSTEM_USERSPACE_TESTSUITE_AT = \ tests/system-userspace-macros.at \ tests/system-userspace-packet-type-aware.at +SYSTEM_AFXDP_TESTSUITE_AT = \ + tests/system-afxdp-testsuite.at \ + tests/system-afxdp-traffic.at \ + tests/system-afxdp-macros.at + SYSTEM_TESTSUITE_AT = \ tests/system-common-macros.at \ tests/system-ovn.at \ @@ -176,6 +183,7 @@ TESTSUITE = $(srcdir)/tests/testsuite TESTSUITE_PATCH = $(srcdir)/tests/testsuite.patch SYSTEM_KMOD_TESTSUITE = $(srcdir)/tests/system-kmod-testsuite SYSTEM_USERSPACE_TESTSUITE = $(srcdir)/tests/system-userspace-testsuite +SYSTEM_AFXDP_TESTSUITE = $(srcdir)/tests/system-afxdp-testsuite SYSTEM_OFFLOADS_TESTSUITE = $(srcdir)/tests/system-offloads-testsuite SYSTEM_DPDK_TESTSUITE = $(srcdir)/tests/system-dpdk-testsuite DISTCLEANFILES += tests/atconfig tests/atlocal @@ -304,6 +312,11 @@ check-system-userspace: all set $(SHELL) '$(SYSTEM_USERSPACE_TESTSUITE)' -C tests AUTOTEST_PATH='$(AUTOTEST_PATH)' $(TESTSUITEFLAGS) -j1; \ "$$@" || (test X'$(RECHECK)' = Xyes && "$$@" --recheck) +check-afxdp: all + $(MAKE) install + set $(SHELL) '$(SYSTEM_AFXDP_TESTSUITE)' -C tests AUTOTEST_PATH='$(AUTOTEST_PATH)' $(TESTSUITEFLAGS) -j1; \ + "$$@" || (test X'$(RECHECK)' = Xyes && "$$@" --recheck) + check-offloads: all set $(SHELL) '$(SYSTEM_OFFLOADS_TESTSUITE)' -C tests AUTOTEST_PATH='$(AUTOTEST_PATH)' $(TESTSUITEFLAGS) -j1; \ "$$@" || (test X'$(RECHECK)' = Xyes && "$$@" --recheck) @@ -336,6 +349,10 @@ $(SYSTEM_USERSPACE_TESTSUITE): package.m4 $(SYSTEM_TESTSUITE_AT) $(SYSTEM_USERSP $(AM_V_GEN)$(AUTOTEST) -I '$(srcdir)' -o $@.tmp $@.at $(AM_V_at)mv $@.tmp $@ +$(SYSTEM_AFXDP_TESTSUITE): package.m4 $(SYSTEM_TESTSUITE_AT) $(SYSTEM_AFXDP_TESTSUITE_AT) $(COMMON_MACROS_AT) + $(AM_V_GEN)$(AUTOTEST) -I '$(srcdir)' -o $@.tmp $@.at + $(AM_V_at)mv $@.tmp $@ + $(SYSTEM_OFFLOADS_TESTSUITE): package.m4 $(SYSTEM_TESTSUITE_AT) $(SYSTEM_OFFLOADS_TESTSUITE_AT) $(COMMON_MACROS_AT) $(AM_V_GEN)$(AUTOTEST) -I '$(srcdir)' -o $@.tmp $@.at $(AM_V_at)mv $@.tmp $@ diff --git a/tests/system-afxdp-macros.at b/tests/system-afxdp-macros.at new file mode 100644 index ..c9d2227f9ab6 --- /dev/null +++ b/tests/system-afxdp-macros.at @@ -0,0 +1,153 @@ +# _ADD_BR([name]) +# +# Expands into the proper ovs-vsctl commands to create a bridge with the +# appropriate type and properties +m4_define([_ADD_BR], [[add-br $1 -- set Bridge $1 datapath_type="netdev" protocols=OpenFlow10,OpenFlow11,OpenFlow12,OpenFlow13,OpenFlow14,OpenFlow15 fail-mode=secure ]]) + +# OVS_TRAFFIC_VSWITCHD_START([vsctl-args], [vsctl-output], [=override]) +# +# Creates a database and starts ovsdb-server, starts ovs-vswitchd +# connected to that database, calls ovs-vsctl to create a bridge named +# br0 with predictable settings, passing 'vsctl-args' as additional +# commands to ovs-vsctl. If 'vsctl-args' causes ovs-vsctl to provide +# output (e.g. because it includes "create" commands) then 'vsctl-output' +# specifies the expected output after filtering through uuidfilt. +m4_define([OVS_TRAFFIC_VSWITCHD_START], + [ + export OVS_PKGDATADIR=$(`pwd`) + _OVS_VSWITCHD_START([--disable-system]) + dnl Add bridges, ports, etc. + OVS_WAIT_WHILE([ip link show br0]) + AT_CHECK([ovs-vsctl -- _ADD_BR([br0]) -- $1 m4_if([$2], [], [], [| uuidfilt])], [0], [$2]) +]) + +# OVS_TRAFFIC_VSWITCHD_STOP([WHITELIST], [extra_cmds]) +# +# Gracefully stops ovs-vswitchd and ovsdb-server, checking their log files +# for messages w
[iovisor-dev] [PATCHv3 RFC 3/3] FIXME: work around the failed cases.
There are still two issues causing some test cases
failed. This patch provides an work-around.
Signed-off-by: William Tu
---
lib/dpif-netdev.c| 2 +-
tests/system-afxdp-macros.at | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index 1564db9c6e44..0a8941309081 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@ -4458,7 +4458,7 @@ rxq_scheduling(struct dp_netdev *dp, bool pinned)
OVS_REQUIRES(dp->port_mutex)
continue;
}
rxqs[i]->pmd = rr_numa_get_pmd(non_local_numa, assign_cyc);
-VLOG_WARN("There's no available (non-isolated) pmd thread "
+VLOG_INFO("There's no available (non-isolated) pmd thread "
"on numa node %d. Queue %d on port \'%s\' will "
"be assigned to the pmd on core %d "
"(numa node %d). Expect reduced performance.",
diff --git a/tests/system-afxdp-macros.at b/tests/system-afxdp-macros.at
index c9d2227f9ab6..062da7020c7a 100644
--- a/tests/system-afxdp-macros.at
+++ b/tests/system-afxdp-macros.at
@@ -37,6 +37,8 @@ m4_define([OVS_TRAFFIC_VSWITCHD_STOP],
[OVS_VSWITCHD_STOP([dnl
$1";/netdev_linux.*obtaining netdev stats via vport failed/d
/dpif_netlink.*Generic Netlink family 'ovs_datapath' does not exist. The Open
vSwitch kernel module is probably not loaded./d
+/dpif_netdev(revalidator.*)|ERR|internal error parsing flow key/d
+/dpif(revalidator.*)|WARN|netdev@ovs-netdev: failed to put/d
"])
AT_CHECK([:; $2])
])
--
2.7.4
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1535): https://lists.iovisor.org/g/iovisor-dev/message/1535
Mute This Topic: https://lists.iovisor.org/mt/28480898/21656
Group Owner: iovisor-dev+ow...@lists.iovisor.org
Unsubscribe: https://lists.iovisor.org/g/iovisor-dev/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[iovisor-dev] [PATCHv3 RFC 0/3] AF_XDP netdev support for OVS
The patch series introduces AF_XDP support for OVS netdev. AF_XDP is a new address family working together with eBPF. In short, a socket with AF_XDP family can receive and send packets from an eBPF/XDP program attached to the netdev. For more details about AF_XDP, please see linux kernel's Documentation/networking/af_xdp.rst OVS has a couple of netdev types, i.e., system, tap, or internal. The patch first adds a new netdev types called "afxdp", and implement its configuration, packet reception, and transmit functions. Since the AF_XDP socket, xsk, operates in userspace, once ovs-vswitchd receives packets from xsk, the proposed architecture re-uses the existing userspace dpif-netdev datapath. As a result, most of the packet processing happens at the userspace instead of linux kernel. Architecure === _ | +---+ | |ovs-vswitchd |<-->ovsdb-server | +---+ | | ofproto |<-->OpenFlow controllers | ++-++ | | netdev | |ofproto-| userspace | ++ | dpif | | | netdev | ++ | |provider| | dpif | | +---||---+ ++ | || | dpif- | | || | netdev | |_ || ++ || _ +---||-++ | | af_xdp prog + | kernel | | xsk_map | |_ +||-+ || physical NIC To simply start, create a ovs userspace bridge using dpif-netdev by setting the datapath_type to netdev: # ovs-vsctl -- add-br br0 -- set Bridge br0 datapath_type=netdev And attach a linux netdev with type afxdp: # ovs-vsctl add-port br0 afxdp-p0 -- \ set interface afxdp-p0 type="afxdp" Documentation = Most of the design details are described in the paper presetned at Linux Plumber 2018, "Bringing the Power of eBPF to Open vSwitch"[1], section 4, and slides[2]. This path uses a not-yet upstreamed feature called XDP_ATTACH[3], described in section 3.1, which is a built-in XDP program for the AF_XDP. This greatly simplifies the management of XDP/eBPF programs. [1] http://vger.kernel.org/lpc_net2018_talks/ovs-ebpf-afxdp.pdf [2] http://vger.kernel.org/lpc_net2018_talks/ovs-ebpf-lpc18-presentation.pdf [3] http://vger.kernel.org/lpc_net2018_talks/lpc18_paper_af_xdp_perf-v2.pdf Test Cases == Test cases are created using namespaces and veth peer, with AF_XDP socket attached to the veth (thus the SKB_MODE). By issuing "make check-afxdp", the patch shows the following: AF_XDP netdev datapath-sanity 1: datapath - ping between two ports ok 2: datapath - http between two ports ok 3: datapath - ping between two ports on vlan ok 4: datapath - ping6 between two ports ok 5: datapath - ping6 between two ports on vlan ok 6: datapath - ping over vxlan tunnel ok 7: datapath - ping over vxlan6 tunnel ok 8: datapath - ping over gre tunnel ok 9: datapath - ping over erspan v1 tunnel ok 10: datapath - ping over erspan v2 tunnel ok 11: datapath - ping over ip6erspan v1 tunnelok 12: datapath - ping over ip6erspan v2 tunnelok 13: datapath - ping over geneve tunnel ok 14: datapath - ping over geneve6 tunnel ok 15: datapath - clone action ok 16: datapath - mpls actions ok 17: datapath - basic truncate actionok conntrack 18: conntrack - controller ok 19: conntrack - force commitok 20: conntrack - ct flush by 5-tuple ok 21: conntrack - IPv4 ping ok 22: conntrack - get_nconns and get/set_maxconns ok 23: conntrack - IPv6 ping ok 24: conntrack - preserve registers ok 25: conntrack - invalid ok 26: conntrack - zones ok 27: conntrack - zones from fieldok 28: conntrack - multiple bridgesok 29: conntrack - multiple zones ok 30: conntrack - multiple namespaces, internal ports skipped (system-afxdp-traffic.at:1298) 31: conntrack - ct_mark ok 32: conntrack - ct_mark bit-fiddlingok system-ovn 36: ovn -- 2 LRs connected via LS, gateway router, SNAT and DNAT ok 37: ovn -- 2 LRs connected via LS, gateway router, easy SNAT ok 38: ovn -- multiple gateway routers, SNAT and DNAT ok 39: ovn -- load-balancing ok 40: ovn -- load-balancing - same subnet.ok 41: ovn -- lo
[iovisor-dev] minutes: IO Visor TSC/Dev Meeting
Thanks all for joining in to the call today. As usual, here are my notes. === Discussion === Jiong: Continuing work on jmp32 - some work on verifier side - needs to work on test support - new test mode with alu 32 option - LLVM in alu 32 mode caused some verifier rejections...investigating Yonghong: Some BTF related bug cleanup Working on LLVM -> BCC -> bpf() functionality prototype - Some dependencies on LLVM/clang patch integration...may cause slowdown Planning to integrate libbpf into libbcc - More updates to be sent to mailing list in next couple weeks William: Continuing OVS/AF_XDP work - Presenting at OVS conf in San Jose - Some further use cases to be presented (tunneling, virtual port) Jakub: Attempted to package bpftool in debian, but ran into gplv3 libbfd linking issue - Will attempt to dual-license and ask permission from contributors, check email - Some concerns about size of library Jesper: Page pool patches are in a working state - Working through prototype code on an arm64 board - Some early integration with the mlnx driver that uses page pools as well ** For version-controlled collaboration on XDP related topics, join Jesper and others using the https://github.com/xdp-project/xdp-project repo John: sockmap/ktls work improvements to enable Cilium use cases Joe: looking into feedback on patches related to signed values === Attendees === Alexei Starovoitov Andy Gospodarek Augusto Caringi David Beckett Jakub Kicinski Jesper Brouer John Fastabend Yonghong Song Paul Chaignon Paul Jardetzky Quentin Monnet William Tu Yifeng Sun Neerav Parikh Brenden Blanco -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1532): https://lists.iovisor.org/g/iovisor-dev/message/1532 Mute This Topic: https://lists.iovisor.org/mt/28479922/21656 Group Owner: iovisor-dev+ow...@lists.iovisor.org Unsubscribe: https://lists.iovisor.org/g/iovisor-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[iovisor-dev] question about per_cpu maps
Dear eBPF community If I understand correctly, per_cpu maps are meant to avoid threading issues, and for example the need to call BPF_XADD to keep counters safe. There is something I am unclear about: - Is it possible for a BPF program to be preempted by another BPF program on the same CPU? If this is the case, it seems that the following scenario could arise: BPF program 1 on cpu 0 reads a counter and is preempted before incrementing it BPF program 2 on cpu 0 reads the same counter, increments it, and finishes BPF program 1 on cpu 0 increments the counter At which point both programs would have read the same value for the counter, with possible problems ensuing. Is this a valid scenario? Am I missing something about how the per_cpu maps are intended to be used? Thanks Pablo Alvarez -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1531): https://lists.iovisor.org/g/iovisor-dev/message/1531 Mute This Topic: https://lists.iovisor.org/mt/28471975/21656 Group Owner: iovisor-dev+ow...@lists.iovisor.org Unsubscribe: https://lists.iovisor.org/g/iovisor-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [iovisor-dev] Recommended LLVM version for bcc 0.7.0
On Wed, Nov 28, 2018 at 7:00 AM Tom Stellard wrote: > > Hi, > > Is there a particular version of LLVM that is recommended to use with > bcc 0.7.0? All LLVM versions ( >= 3.7.1) should work for x86, but to use some features like BPF debug=8 to dump the source embedded byte code, you need llvm 6.0 or later. > > Thanks, > Tom > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1530): https://lists.iovisor.org/g/iovisor-dev/message/1530 Mute This Topic: https://lists.iovisor.org/mt/28431236/21656 Group Owner: iovisor-dev+ow...@lists.iovisor.org Unsubscribe: https://lists.iovisor.org/g/iovisor-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[iovisor-dev] Recommended LLVM version for bcc 0.7.0
Hi, Is there a particular version of LLVM that is recommended to use with bcc 0.7.0? Thanks, Tom -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1529): https://lists.iovisor.org/g/iovisor-dev/message/1529 Mute This Topic: https://lists.iovisor.org/mt/28431236/21656 Group Owner: iovisor-dev+ow...@lists.iovisor.org Unsubscribe: https://lists.iovisor.org/g/iovisor-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
