Re: [ovs-dev] [PATCH v11] OVN: Enable E-W Traffic, Vlan backed DVR
On Tue, Jun 18, 2019 at 2:10 AM Ankur Sharma
wrote:
> Background:
> [1]
> https://mail.openvswitch.org/pipermail/ovs-dev/2018-October/353066.html
> [2]
> https://docs.google.com/document/d/1uoQH478wM1OZ16HrxzbOUvk5LvFnfNEWbkPT6Zmm9OU/edit?usp=sharing
>
> Key difference between an overlay logical switch and
> vlan backed logical switch is that for vlan logical switches
> packets are not encapsulated.
>
> Hence, if a distributed router port is connected to vlan backed
> logical switch, then router port mac as source mac could be
> seen from multiple hypervisors. Same pairs coming
> from multiple ports from a top of the rack switch (TOR) perspective
> could be seen as a security threat and it could send alarms, drop
> the packets or block the ports etc.
>
> This patch addresses the same by introducing the concept of chassis mac.
> A chassis mac is CMS provisioned unique mac per chassis. For any routed
> packet
> (i.e source mac is router port mac) going on the wire on a vlan type
> logical switch, we will replace its source mac with chassis mac.
>
> This replacing of source mac with chassis mac will happen in table=65
> of the logical switch datapath. A flow is added at priority 150, which
> matches the source mac and replaces it with chassis mac if the value
> is a router port mac.
>
> Example flow:
> cookie=0x0, duration=67765.830s, table=65, n_packets=0, n_bytes=0,
> idle_age=65534, hard_age=65534, priority=150,reg15=0x1,metadata=0x4,
> dl_src=00:00:01:01:02:03 actions=mod_dl_src:aa:bb:cc:dd:ee:ff,
> mod_vlan_vid:1000,output:16
>
> Here, 00:00:01:01:02:03 is router port mac and aa:bb:cc:dd:ee:ff
> is chassis mac.
>
> Signed-off-by: Ankur Sharma
> Acked-by: Numan Siddique
>
Hi Ankur,
Can you please take a look at this -
https://mail.openvswitch.org/pipermail/ovs-build/2019-June/008433.html
and
https://travis-ci.org/ovsrobot/ovs/builds/546951509?utm_medium=notification_source=email
Looks like there are compiler warnings when configured with --no-ssl. See
the failed jobs.
Thanks
Numan
> ---
> ovn/controller/binding.c| 12 +--
> ovn/controller/chassis.c| 64 +++-
> ovn/controller/chassis.h| 4 +
> ovn/controller/ovn-controller.8.xml | 10 ++
> ovn/controller/ovn-controller.c | 4 +-
> ovn/controller/ovn-controller.h | 5 +-
> ovn/controller/physical.c | 95 ++
> ovn/ovn-architecture.7.xml | 24 +
> ovn/ovn-sb.xml | 8 ++
> tests/ovn.at| 195
>
> 10 files changed, 409 insertions(+), 12 deletions(-)
>
> diff --git a/ovn/controller/binding.c b/ovn/controller/binding.c
> index 87d0b6d..ace0f81 100644
> --- a/ovn/controller/binding.c
> +++ b/ovn/controller/binding.c
> @@ -159,13 +159,11 @@ add_local_datapath__(struct ovsdb_idl_index
> *sbrec_datapath_binding_by_key,
> sbrec_port_binding_by_name,
> peer->datapath, false,
> depth + 1, local_datapaths);
> -ld->n_peer_dps++;
> -ld->peer_dps = xrealloc(
> -ld->peer_dps,
> -ld->n_peer_dps * sizeof *ld->peer_dps);
> -ld->peer_dps[ld->n_peer_dps - 1] =
> datapath_lookup_by_key(
> -sbrec_datapath_binding_by_key,
> -peer->datapath->tunnel_key);
> +ld->n_peer_ports++;
> +ld->peer_ports = xrealloc(ld->peer_ports,
> + ld->n_peer_ports *
> + sizeof *ld->peer_ports);
> +ld->peer_ports[ld->n_peer_ports - 1] = peer;
> }
> }
> }
> diff --git a/ovn/controller/chassis.c b/ovn/controller/chassis.c
> index 0f537f1..8403212 100644
> --- a/ovn/controller/chassis.c
> +++ b/ovn/controller/chassis.c
> @@ -23,6 +23,7 @@
> #include "lib/vswitch-idl.h"
> #include "openvswitch/dynamic-string.h"
> #include "openvswitch/vlog.h"
> +#include "openvswitch/ofp-parse.h"
> #include "ovn/lib/chassis-index.h"
> #include "ovn/lib/ovn-sb-idl.h"
> #include "ovn-controller.h"
> @@ -69,6 +70,12 @@ get_bridge_mappings(const struct smap *ext_ids)
> }
>
> static const char *
> +get_chassis_mac_mappings(const struct smap *ext_ids)
> +{
> +return smap_get_def(ext_ids, "ovn-chassis-mac-mappings", "");
> +}
> +
> +static const char *
> get_cms_options(const struct smap *ext_ids)
> {
> return smap_get_def(ext_ids, "ovn-cms-options", "");
> @@ -162,6 +169,7 @@ chassis_run(struct ovsdb_idl_txn *ovnsb_idl_txn,
> const char *datapath_type =
> br_int && br_int->datapath_type ? br_int->datapath_type : "";
> const char *cms_options = get_cms_options(>external_ids);
> +const char *chassis_macs =
>
[ovs-dev] [PATCH] ofproto-dpif-upcall: Remove unused macro MAX_QUEUE_LENGTH.
Signed-off-by: Yunjian Wang --- ofproto/ofproto-dpif-upcall.c | 1 - 1 file changed, 1 deletion(-) diff --git a/ofproto/ofproto-dpif-upcall.c b/ofproto/ofproto-dpif-upcall.c index a19aa95..196ce01 100644 --- a/ofproto/ofproto-dpif-upcall.c +++ b/ofproto/ofproto-dpif-upcall.c @@ -45,7 +45,6 @@ #include "openvswitch/vlog.h" #include "lib/netdev-provider.h" -#define MAX_QUEUE_LENGTH 512 #define UPCALL_MAX_BATCH 64 #define REVALIDATE_MAX_BATCH 50 -- 1.8.3.1 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCHv12] netdev-afxdp: add new netdev type for AF_XDP.
Bleep bloop. Greetings William Tu, I am a robot and I have tried out your patch. Thanks for your contribution. I encountered some error that I wasn't expecting. See the details below. git-am: Failed to merge in the changes. Patch failed at 0001 netdev-afxdp: add new netdev type for AF_XDP. The copy of the patch that failed is found in: /var/lib/jenkins/jobs/upstream_build_from_pw/workspace/.git/rebase-apply/patch When you have resolved this problem, run "git am --resolved". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". Please check this out. If you feel there has been an error, please email acon...@bytheb.org Thanks, 0-day Robot ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCHv12] netdev-afxdp: add new netdev type for AF_XDP.
The patch introduces experimental AF_XDP support for OVS netdev.
AF_XDP, the Address Family of the eXpress Data Path, is a new Linux socket
type built upon the eBPF and XDP technology. It is aims to have comparable
performance to DPDK but cooperate better with existing kernel's networking
stack. An AF_XDP socket receives and sends packets from an eBPF/XDP program
attached to the netdev, by-passing a couple of Linux kernel's subsystems
As a result, AF_XDP socket shows much better performance than AF_PACKET
For more details about AF_XDP, please see linux kernel's
Documentation/networking/af_xdp.rst. Note that by default, this feature is
not compiled in.
Signed-off-by: William Tu
---
v1->v2:
- add a list to maintain unused umem elements
- remove copy from rx umem to ovs internal buffer
- use hugetlb to reduce misses (not much difference)
- use pmd mode netdev in OVS (huge performance improve)
- remove malloc dp_packet, instead put dp_packet in umem
v2->v3:
- rebase on the OVS master, 7ab4b0653784
("configure: Check for more specific function to pull in pthread library.")
- remove the dependency on libbpf and dpif-bpf.
instead, use the built-in XDP_ATTACH feature.
- data structure optimizations for better performance, see[1]
- more test cases support
v3: https://mail.openvswitch.org/pipermail/ovs-dev/2018-November/354179.html
v3->v4:
- Use AF_XDP API provided by libbpf
- Remove the dependency on XDP_ATTACH kernel patch set
- Add documentation, bpf.rst
v4->v5:
- rebase to master
- remove rfc, squash all into a single patch
- add --enable-afxdp, so by default, AF_XDP is not compiled
- add options: xdpmode=drv,skb
- add multiple queue and multiple PMD support, with options: n_rxq
- improve documentation, rename bpf.rst to af_xdp.rst
v5->v6
- rebase to master, commit 0cdd5b13de91b98
- address errors from sparse and clang
- pass travis-ci test
- address feedback from Ben
- fix issues reported by 0-day robot
- improved documentation
v6-v7
- rebase to master, commit abf11558c1515bf3b1
- address feedbacks from Ilya, Ben, and Eelco, see:
https://www.mail-archive.com/ovs-dev@openvswitch.org/msg32357.html
- add XDP mode change, implement get/set_config, reconfigure
- Fix reconfiguration/crash issue caused by libbpf, see patch:
[PATCH bpf 0/2] libbpf: fixes for AF_XDP teardown
- perf optimization for batching umem_push/pop
- perf optimization for batching kick_tx
- test build with dpdk
- fix/refactor atomic operation
- make AF_XDP x86 specific, otherwise fail at build time
- lots of code refactoring
- add PVP setup in documentation
v7-v8:
- Address feedback from Ilya at:
https://patchwork.ozlabs.org/patch/1095019/
- add netdev-linux-private.h
- fix afxdp reconfigure issue
- sort include headers
- remove unnecessary OVS_UNUSED
- coding style fixes
- error case handling and memory leak
v8-v9:
- rebase to master 180bbbed3a3867d52
- Address review feedback from Ben, Ilya and Eelco, at:
https://patchwork.ozlabs.org/patch/1097740/
- == From Ilya ==
- Optimize the reconfiguration logic
- Implement .rxq_recv and .send for afxdp
- Remove system-afxdp-traffic.at, reuse existing code
- Use Ilya's rdtsc code
- remove --disable-system
- == From Eelco ==
- Fix bug when remove br0, util(revalidator49)|EMER|lib/poll-loop.c:111:
assertion !fd != !wevent failed
- Fix bug and use default value from libbpf, ex: XSK_RING_PROD__DEFAULT...
- Clear xdp program when receive signal, ctrl+c
- Add options to vswitch.xml, set xdpmode default to skb-mode
- No support for ARM and PPC, now x86_64 only
- remove redundant header includes and function/macro definitions
- remove some ifdef HAVE_AF_XDP
- == From others/both about afxdp rx and tx ==
- Several umem push/pop error handling improvement/fixes
- add lock to address concurrent_txq case
- improve error handling
- add stats
- Things that are not done yet
- MTU limitation
- n_txq_desc/n_rxq_desc option.
v9-v10
- remove x86_64 limitation, suggested by Ben and Eelco
- add xmalloc_pagealign, free_pagealign
- minor refector
v10-v11
- address feedback from Ilya at
https://patchwork.ozlabs.org/patch/1106495/
- fix typos, and some refactoring
- refactor existing code and introduce xmalloc pagealign
- fix a couple of error handling case
- allocate per-txq lock
- dynamic allocate xsk array
- fix cycle_counter_update() for non-x86/non-linux case
v11-v12
- mainly address a couple of crashes reported by Eelco
https://patchwork.ozlabs.org/patch/1110729/
- fix cleanup xdp program problem when ovs-vswtichd restarts
- following cases should remove xdp program
- kill `pidof ovs-vswitchd`
- ovs-appctl -t ovs-vswtichd exit --cleanup
- note: ovs-ctl restart does not have "--cleanup" so still an issue
- work around issues of xsk_ring_cons__peek at libbpf, reported at
https://marc.info/?l=xdp-newbies=156055471727857=2
- variable name refactoring
- there are some performance degradation, but let's make sure
everything works first
---
Documentation/automake.mk | 1 +
Re: [ovs-dev] [PATCHv11] netdev-afxdp: add new netdev type for AF_XDP.
> The PVP test seems to work fine however after a while it stops > forwarding: > > $ ovs-ofctl dump-flows ovs_pvp_br0 > cookie=0x0, duration=8.510s, table=0, n_packets=1, n_bytes=1020, > in_port=eno1 actions=output:tapVM > cookie=0x0, duration=8.504s, table=0, n_packets=1, n_bytes=252, > in_port=tapVM actions=output:eno1 > > Results: > > "Physical port, ""eno1"", speed 10 Gbit/s, traffic rate 100%" > "Physical to Virtual to Physical test, L3 flows[port redirect]" > ,Packet size > Number of flows,64,256,1024 > 10,13448,131687,0 > 100,596,0,0 > 1000,596,0,0 > I'm not able to reproduce this issue... Hopefully next version we can find out more about the root cause. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCHv11] netdev-afxdp: add new netdev type for AF_XDP.
>
> I guess, this crash caused by trying to destroy unallocated queue.
>
> Following change could help:
> ---
> diff --git a/lib/netdev-afxdp.c b/lib/netdev-afxdp.c
> index a6543e8f5..6e1431dce 100644
> --- a/lib/netdev-afxdp.c
> +++ b/lib/netdev-afxdp.c
> @@ -249,7 +249,7 @@ xsk_configure_all(struct netdev *netdev)
> ifindex = linux_get_ifindex(netdev_get_name(netdev));
>
> n_rxq = netdev_n_rxq(netdev);
> -dev->xsks = xmalloc(n_rxq * sizeof(struct xsk_socket_info *));
> +dev->xsks = xzalloc(n_rxq * sizeof(struct xsk_socket_info *));
>
> /* configure each queue */
> for (i = 0; i < n_rxq; i++) {
> ---
>
> This should prevent OVS from crash, however, I don't know why socket
> creation fails in your case.
>
Hi Ilya,
Thanks, I will add this into my next version.
@Eelco
When using ovs-ctl restart, it still fails, but this is because userspace
datapath need extra "--cleanup" argument, s.t like
#ovs-appctl -t ovs-vswitchd --cleanup
We should add it to stop_daemon() at utilities/ovs-lib.in
Regards,
William
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v2] Detailed packet drop statistics per dpdk and vhostuser ports
On 18/06/2019 15:05, Kevin Traynor wrote:
> Hi Sriram,
>
> On 14/06/2019 14:38, Sriram Vatala via dev wrote:
>> OVS may be unable to transmit packets for multiple reasons and
>> today there is a single counter to track packets dropped due to
>> any of those reasons. The most common reason is that a VM is
>> unable to read packets fast enough causing the vhostuser port
>> transmit queue on the OVS side to become full. This manifests
>> as a problem with VNFs not receiving all packets. Having a
>> separate drop counter to track packets dropped because the
>> transmit queue is full will clearly indicate that the problem
>> is on the VM side and not in OVS. Similarly maintaining separate
>> counters for all possible drops helps in indicating sensible
>> cause for packet drops.
>>
>> This patch adds counters to track packets dropped due to all
>> possible reasons and these counters are displayed along with
>> other stats in "ovs-vsctl get interface statistics"
>> command. The detailed stats will be available for both dpdk and
>> vhostuser ports.
>>
>> Following are the details of the new counters :
>>
>> tx_qfull_drops : These are the packets dropped due to
>> transmit queue overrun.
>>
>
> I'm not sure about this name, you would need to know that it was the
> only reason rte_eth_tx_burst() and rte_vhost_enqueue_burst() will not
> send pkts
>
>> tx_mtu_exceeded_drops : These are the packets dropped due
>> to MTU mismatch (i.e Pkt len > Max Dev MTU).
>>
>> tx_qos_drops/rx_qos_drops : These are the packets dropped due
>> to transmission/reception rate exceeding the configured
>> Egress/Ingress policer rate on the interface.
>>
>
> I think you also need to update vswitchd.xml with some docs for these stats
>
Actually, it doesn't seem needed there, perhaps something in the dpdk docs
>> diff --git a/vswitchd/bridge.c b/vswitchd/bridge.c
>> index 0702cc6..2cb5558 100644
>> --- a/vswitchd/bridge.c
>> +++ b/vswitchd/bridge.c
>> @@ -2407,7 +2407,11 @@ iface_refresh_stats(struct iface *iface)
>> IFACE_STAT(rx_undersized_errors,"rx_undersized_errors") \
>> IFACE_STAT(rx_oversize_errors, "rx_oversize_errors") \
>> IFACE_STAT(rx_fragmented_errors,"rx_fragmented_errors") \
>> -IFACE_STAT(rx_jabber_errors,"rx_jabber_errors")
>> +IFACE_STAT(rx_jabber_errors,"rx_jabber_errors") \
>> +IFACE_STAT(rx_qos_drops,"rx_qos_drops") \
>> +IFACE_STAT(tx_qfull_drops, "tx_qfull_drops") \
>> +IFACE_STAT(tx_qos_drops,"tx_qos_drops") \
>> +IFACE_STAT(tx_mtu_drops,"tx_mtu_exceeded_drops")
>>
>> #define IFACE_STAT(MEMBER, NAME) + 1
>> enum { N_IFACE_STATS = IFACE_STATS };
>>
>
> What about updating show_dpif() to print with ovs-appctl dpctl/show -s ?
>
scratch that comment, I since saw the discussion on v1
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCHv11] netdev-afxdp: add new netdev type for AF_XDP.
> > I’m using an RHEL7 instance and use systemd to restart openvswitch > with “systemctl restart openvswitch”. > It uses ovs-ctl to stat/stop, see here for some details: > > https://github.com/openvswitch/ovs/blob/master/rhel/usr_lib_systemd_system_ovs-vswitchd.service.in > > Thanks Eelco, I can reproduce this issue now. Basically, if I start OVS with afxdp port, then # kill `pidof ovs-vswitchd` trigger the call to signal_remove_xdp() # ip -s link show Then the xdp program is still there due to a bug in xsk_remove_xdp_program (where I save prog_id as static) I will fix it in next version! Thanks William ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] История государства Российского — уникальная видеоколлекция в отличном качестве. 13_05_2019 02_03 198707
ИСТОРИЯ ГОСУДАРСТВА РОССИЙСКОГО Цикл "История государства Российского" созданный по фундаментальному одноименному труду выдающегося литератора и историка российской культуры 19 века Николая Михайловича Карамзина и дополненный сочинениями Николая Ивановича Костомарова «Русская история в жизнеописаниях ее главнейших деятелей» и Сергея Михайловича Соловьёва «История России с древнейших времен», состоит из 500 серий. Проект охватывает события истории Российского государства от момента его создания и до конца правления Екатерины II. Каждая серия - плод усилий большого творческого коллектива, состоящего из десятков людей разных профессий: модельеров трехмерной графики, которые выполняют сотни фигур воинов, крестьян, ремесленников, модели городов; аниматоров, оживляющих персонажи; "компоузеров", собирающих, как из конструктора, серию в целом. И, разумеется, редакторов, художников-постановщиков, музыкантов... И в результате на экране - "ожившие" древние карты, сцены походов и битв, виды древнерусских городов и исторически достоверные пейзажи, тщательно проработанные детали одежды, оружия, утвари наших предков, их дальних и ближних соседей, отвечающие реалиям сменяющихся исторических эпох. "История государства Российского" - это не просто учебник истории. Главная задача проекта - вызвать интерес к ней, показать, что наша история - не пожелтевшие страницы пыльных фолиантов, а увлекательное повествование о жизни великой страны, яркие биографии совершенно реальных людей, умом и волей которых формировались русское государство и нация в целом. Закадровый текст читает певец и композитор Юрий Шевчук. ! Список серий, описание каждой из них, вы можете увидеть в прикреплённом к письму файле ! Коллекция состоит из 500 серий. Записана на внешний USB накопитель (флешка). Проблем с воспроизведением не возникнет, можно смотреть на компьютере, планшете, смартфоне, телевизоре и т.д. Запись на внешний USB накопитель имеет ряд преимуществ в сравнении с обычными DVD дисками, USB накопитель гораздо легче, занимает меньше места, обладает высокой надёжностью сохранности записей, а это значит, что наша коллекция будет радовать Вас много лет. Мы гарантируем отличное качество всех записей. На самом носителе создана продуманная структура, все записи разнесены по каталогам, имеются плейлисты, прописаны теги, а также полный список вошедших записей, поэтому проблем с поиском и навигацией не возникнет. Стоимость коллекции на внешнем USB накопителе — 6500 (Шесть Тысяч Пятьсот) Рублей. Продаются только вместе. Доставка включена в стоимость. Доставка только почтой по всей России, сроки 7-14 суток с момента отправки. Оплата в момент получения заказа на почте наложенным платежом. У нас нет курьерской доставки — только почтой, в том числе и по Москве. Для оформления заказа просьба не забывать указывать: --- Ваш почтовый индекс (пишите правильный индекс — это ускорит доставку); --- Ваш город и точный адрес (название улицы, номер дома и номер квартиры); --- Ф.И.О. получателя и ОБЯЗАТЕЛЬНО номер контактного телефона (лучше сотовый); Заказы\вопросы направляйте по адресу: historyruss...@cwhflash.ru Мы очень ответственно относимся к качеству нашего товара, поэтому перед отправкой всё дополнительно проверяется, как следствие отправка бракованной продукции сведена к нулю. Товар упаковывается в специальный ударостойкий материал, что в значительной степени уменьшает риск повреждения при транспортировке. Если вдруг с полученным товаром возникнут проблемы, то все наши покупатели всегда могут рассчитывать на квалифицированную техническую поддержку. Мы никогда не отказываемся от гарантийных обязательств, в случае проблемы Вы можете рассчитывать на замену, почтовые расходы мы берём на себя. По вашему желанию, данная коллекция может быть записана на DVD диски. Для записи используются надёжные DVD диски со специальным покрытием, которое повышает устойчивость диска к механическим повреждениям, таким как трещины и царапины, а это значит, что наша коллекция будет радовать Вас много лет. Коллекция упакована в пластиковые боксы (slim-dvd), имеет красивые и продуманные обложки, с обратной стороны которых указан список вошедших на каждый диск серий и другая полезная информация, поэтому проблем с поиском и навигацией не возникнет. Если хотите приобрести коллекцию, записанную на DVD дисках, то в этом случае просьба сообщить нам об этом в своей заявке, цена прежняя, как у версии на внешнем USB накопителе (флешка) — 6500 (Шесть Тысяч Пятьсот) Рублей. Если вы не хотите больше получать от нас письма, отправьте нам письмо с темой “deletemail” и Ваш адрес навсегда будет удален автоматически. 13_05_2019 02_03 198707 ovs-dev@openvswitch.org ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH 2/2] travis: Make it possible to build against a dpdk branch.
On Tue, Jun 18, 2019 at 5:24 PM Ilya Maximets
wrote:
> On 12.06.2019 12:21, David Marchand wrote:
> > Rework the build script so that we can pass branches and tags.
> >
> > With this, DPDK_VER can be passed as:
> > - a string starting with refs/ which is understood as a git reference.
> > This triggers a git clone on DPDK_GIT (default value points to
> > https://dpdk.org/git/dpdk) for a single branch pointing to this
> > reference (to save some disk),
> > - else, any other string which is understood as an official release.
> > This triggers a tarball download on dpdk.org.
> >
> > Signed-off-by: David Marchand
> > ---
> > .travis/linux-build.sh | 13 -
> > 1 file changed, 8 insertions(+), 5 deletions(-)
> >
> > diff --git a/.travis/linux-build.sh b/.travis/linux-build.sh
> > index cd8cfcf..ddba2db 100755
> > --- a/.travis/linux-build.sh
> > +++ b/.travis/linux-build.sh
> > @@ -63,10 +63,13 @@ function install_kernel()
> >
> > function install_dpdk()
> > {
> > -if [ -n "$DPDK_GIT" ]; then
> > -git clone $DPDK_GIT dpdk-$1
> > -cd dpdk-$1
> > -git checkout tags/v$1
> > +if [ "${1##refs/*/}" != "${1}" ]; then
> > +DPDK_GIT=${DPDK_GIT:-https://dpdk.org/git/dpdk}
> > +ref="${1##refs/*/}"
> > +git clone --single-branch $DPDK_GIT dpdk-git -b $ref
> > +name=$(git --git-dir=dpdk-git/.git describe)
> > +mv dpdk-git dpdk-$name
>
> Renaming the directory seems redundant.
> Also, as you're moving EXTRA_OPTS update to this function we don't need
> standardised folder names anymore. So, you could remove the renaming from
> the 'else' branch too. Just 'cd dpdk-git' here and 'cd $DIR_NAME' there.
> If you want the exact revision of the branch you're right now for debugging
> reasons, you may print it to stdout like 'git log -1 --oneline' and it will
> be kept in travis logs.
>
I usually don't like to scroll back the whole log to find the revision,
this is why I had put it in the directory name.
But I suppose I should first look at the revision before going to the build
errors ;-)
Ok, I will remove this, anything else?
--
David Marchand
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [RFC] ofproto-dpif-xlate: Flood the updates for learning tables through peers.
On Tue, Jun 18, 2019 at 05:29:30PM +0300, Ilya Maximets wrote: > Since bridges connected via patch ports are almost the same L2 bridge, > they should share L2 learning information in order to avoid such > conditions. > > This could be implemented by flooding of the mac learning information > over the patch ports while updating the learning tables. > > Signed-off-by: Ilya Maximets This idea is interesting to me because it breaks my idea of how bridges connected by patch ports work. My conception of such bridges has been that they are almost completely independent; their only connection is the patch port, which acts just like connecting two switches with a physical cable. I am not aware of violations of this model currently, but I believe that this change would violate it. I am not going to insist on retaining the model--I do not know whether it is truly helpful, and this patch seems beneficial--but I want to point out that we're making a conceptual change ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH 2/2] travis: Make it possible to build against a dpdk branch.
On 12.06.2019 12:21, David Marchand wrote:
> Rework the build script so that we can pass branches and tags.
>
> With this, DPDK_VER can be passed as:
> - a string starting with refs/ which is understood as a git reference.
> This triggers a git clone on DPDK_GIT (default value points to
> https://dpdk.org/git/dpdk) for a single branch pointing to this
> reference (to save some disk),
> - else, any other string which is understood as an official release.
> This triggers a tarball download on dpdk.org.
>
> Signed-off-by: David Marchand
> ---
> .travis/linux-build.sh | 13 -
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/.travis/linux-build.sh b/.travis/linux-build.sh
> index cd8cfcf..ddba2db 100755
> --- a/.travis/linux-build.sh
> +++ b/.travis/linux-build.sh
> @@ -63,10 +63,13 @@ function install_kernel()
>
> function install_dpdk()
> {
> -if [ -n "$DPDK_GIT" ]; then
> -git clone $DPDK_GIT dpdk-$1
> -cd dpdk-$1
> -git checkout tags/v$1
> +if [ "${1##refs/*/}" != "${1}" ]; then
> +DPDK_GIT=${DPDK_GIT:-https://dpdk.org/git/dpdk}
> +ref="${1##refs/*/}"
> +git clone --single-branch $DPDK_GIT dpdk-git -b $ref
> +name=$(git --git-dir=dpdk-git/.git describe)
> +mv dpdk-git dpdk-$name
Renaming the directory seems redundant.
Also, as you're moving EXTRA_OPTS update to this function we don't need
standardised folder names anymore. So, you could remove the renaming from
the 'else' branch too. Just 'cd dpdk-git' here and 'cd $DIR_NAME' there.
If you want the exact revision of the branch you're right now for debugging
reasons, you may print it to stdout like 'git log -1 --oneline' and it will
be kept in travis logs.
> +cd dpdk-$name
> else
> wget https://fast.dpdk.org/rel/dpdk-$1.tar.xz
> tar xvf dpdk-$1.tar.xz > /dev/null
> @@ -87,6 +90,7 @@ function install_dpdk()
> sed -i '/CONFIG_RTE_KNI_KMOD=y/s/=y/=n/' build/.config
>
> make -j4 CC=gcc EXTRA_CFLAGS='-fPIC'
> +EXTRA_OPTS="$EXTRA_OPTS --with-dpdk=$(pwd)/build"
> echo "Installed DPDK source in $(pwd)"
> cd ..
> }
> @@ -109,7 +113,6 @@ if [ "$DPDK" ] || [ "$DPDK_SHARED" ]; then
> # Disregard cast alignment errors until DPDK is fixed
> CFLAGS="$CFLAGS -Wno-cast-align"
> fi
> -EXTRA_OPTS="$EXTRA_OPTS --with-dpdk=$(pwd)/dpdk-$DPDK_VER/build"
> fi
>
> OPTS="$EXTRA_OPTS $*"
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [RFC] ofproto-dpif-xlate: Flood the updates for learning tables through peers.
Consider following setup:
br0:
phy-port
random-port
patch-to-br-int
br-int:
port-1
port-2
patch-to-br0
And the expected traffic pattern:
phy-port ---> port-1 ---> port-2 ---> phy-port
For example, this could be done if 'port-1' and 'port-2' are ports of
two VMs and we have some service chain PHY --> VM1 --> VM2 --> PHY.
In case we have a unidirectional packet stream (UDP), VM1 will never
send packets outside the integration bridge (br-int). This will lead
to situation where the physical bridge (br0) will expire the mac of
'port-1' from the mac learning table after some time and will never
know it again, causing constant flooding inside the physical bridge
(br0):
# ovs-appctl ofproto/trace \
br0 "in_port=phy-port,ip,eth_src=,eth_dst="
Flow: ip,in_port=1,dl_src=,dl_dst=
bridge("br0")
-
0. priority 0
NORMAL
-> no learned MAC for destination, flooding
bridge("br-int")
0. in_port=patch-to-br0, priority 0
NORMAL
-> forwarding to learned port
Final flow: unchanged
Megaflow: recirc_id=0,eth,ip,in_port=phy-port,dl_src=,dl_dst=
Datapath actions: br0,random-port,port-1
This is unwanted because 'br-int' knows that the desired mac is behind
the 'port-1' and sends packets directly, while 'br0' keeps flooding the
packets to all the ports significantly reducing performance.
Since bridges connected via patch ports are almost the same L2 bridge,
they should share L2 learning information in order to avoid such
conditions.
This could be implemented by flooding of the mac learning information
over the patch ports while updating the learning tables.
Signed-off-by: Ilya Maximets
---
Not fully tested.
ofproto/ofproto-dpif-xlate.c | 66
1 file changed, 59 insertions(+), 7 deletions(-)
diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
index 73966a4e8..11d04e049 100644
--- a/ofproto/ofproto-dpif-xlate.c
+++ b/ofproto/ofproto-dpif-xlate.c
@@ -34,6 +34,7 @@
#include "csum.h"
#include "dp-packet.h"
#include "dpif.h"
+#include "hmapx.h"
#include "in-band.h"
#include "lacp.h"
#include "learn.h"
@@ -544,7 +545,7 @@ static void xlate_table_action(struct xlate_ctx *,
ofp_port_t in_port,
bool is_last_action, xlate_actions_handler *);
static bool input_vid_is_valid(const struct xlate_ctx *,
- uint16_t vid, struct xbundle *);
+ uint16_t vid, const struct xbundle *);
static void xvlan_copy(struct xvlan *dst, const struct xvlan *src);
static void xvlan_pop(struct xvlan *src);
static void xvlan_push_uninit(struct xvlan *src);
@@ -2181,7 +2182,7 @@ mirror_ingress_packet(struct xlate_ctx *ctx)
* 0...4095. */
static bool
input_vid_is_valid(const struct xlate_ctx *ctx,
- uint16_t vid, struct xbundle *in_xbundle)
+ uint16_t vid, const struct xbundle *in_xbundle)
{
/* Allow any VID on the OFPP_NONE port. */
if (in_xbundle == _none_bundle) {
@@ -2554,7 +2555,8 @@ is_admissible(struct xlate_ctx *ctx, struct xport
*in_port,
static bool
update_learning_table__(const struct xbridge *xbridge,
-struct xbundle *in_xbundle, struct eth_addr dl_src,
+const struct xbundle *in_xbundle,
+struct eth_addr dl_src,
int vlan, bool is_grat_arp)
{
return (in_xbundle == _none_bundle
@@ -2565,10 +2567,48 @@ update_learning_table__(const struct xbridge *xbridge,
}
static void
-update_learning_table(const struct xlate_ctx *ctx,
- struct xbundle *in_xbundle, struct eth_addr dl_src,
- int vlan, bool is_grat_arp)
+update_learning_table_with_flood(struct xlate_ctx *ctx,
+ const struct xbundle *in_xbundle,
+ struct eth_addr dl_src,
+ const struct xvlan *xvlan, bool is_grat_arp,
+ struct hmapx *updated_bridges)
{
+struct xport *xport;
+int vlan = xvlan->v[0].vid;
+
+/* Prevent updating the same bridge twice. */
+hmapx_add(updated_bridges, CONST_CAST(void *, ctx->xbridge));
+
+/* Flooding the mac updates through the peers. */
+HMAP_FOR_EACH (xport, ofp_node, >xbridge->xports) {
+if (xport->peer
+&& !hmapx_contains(updated_bridges, xport->peer->xbridge)
+&& xport->xbundle
+&& xport->xbundle != in_xbundle
+&& xport->xbundle->ofbundle != in_xbundle->ofbundle
+&& xbundle_includes_vlan(xport->xbundle, xvlan)
+&& xport->xbundle->floodable
+&& !xbundle_mirror_out(ctx->xbridge, xport->xbundle)) {
+
+const struct xbridge *xbridge_orig = ctx->xbridge;
+const struct xbundle *peer_xbundle = xport->peer->xbundle;
+
Re: [ovs-dev] [PATCH v2] Detailed packet drop statistics per dpdk and vhostuser ports
Hi Sriram,
On 14/06/2019 14:38, Sriram Vatala via dev wrote:
> OVS may be unable to transmit packets for multiple reasons and
> today there is a single counter to track packets dropped due to
> any of those reasons. The most common reason is that a VM is
> unable to read packets fast enough causing the vhostuser port
> transmit queue on the OVS side to become full. This manifests
> as a problem with VNFs not receiving all packets. Having a
> separate drop counter to track packets dropped because the
> transmit queue is full will clearly indicate that the problem
> is on the VM side and not in OVS. Similarly maintaining separate
> counters for all possible drops helps in indicating sensible
> cause for packet drops.
>
> This patch adds counters to track packets dropped due to all
> possible reasons and these counters are displayed along with
> other stats in "ovs-vsctl get interface statistics"
> command. The detailed stats will be available for both dpdk and
> vhostuser ports.
>
> Following are the details of the new counters :
>
> tx_qfull_drops : These are the packets dropped due to
> transmit queue overrun.
>
I'm not sure about this name, you would need to know that it was the
only reason rte_eth_tx_burst() and rte_vhost_enqueue_burst() will not
send pkts
> tx_mtu_exceeded_drops : These are the packets dropped due
> to MTU mismatch (i.e Pkt len > Max Dev MTU).
>
> tx_qos_drops/rx_qos_drops : These are the packets dropped due
> to transmission/reception rate exceeding the configured
> Egress/Ingress policer rate on the interface.
>
I think you also need to update vswitchd.xml with some docs for these stats
> Signed-off-by: Sriram Vatala
> ---
> include/openvswitch/netdev.h | 8
> lib/netdev-dpdk.c | 49
> ++
> utilities/bugtool/automake.mk | 3 +-
> utilities/bugtool/ovs-bugtool-get-iface-stats | 25 +++
> .../bugtool/plugins/network-status/openvswitch.xml | 3 ++
> vswitchd/bridge.c | 6 ++-
> 6 files changed, 85 insertions(+), 9 deletions(-)
> create mode 100755 utilities/bugtool/ovs-bugtool-get-iface-stats
>
> diff --git a/include/openvswitch/netdev.h b/include/openvswitch/netdev.h
> index 0c10f7b..69480a4 100644
> --- a/include/openvswitch/netdev.h
> +++ b/include/openvswitch/netdev.h
> @@ -61,6 +61,14 @@ struct netdev_stats {
> uint64_t tx_heartbeat_errors;
> uint64_t tx_window_errors;
>
> +/* Detailed receive drops. */
> +uint64_t rx_qos_drops;
> +
> +/* Detailed transmit drops. */
> +uint64_t tx_qfull_drops;
> +uint64_t tx_qos_drops;
> +uint64_t tx_mtu_drops;
> +
> /* Extended statistics based on RFC2819. */
> uint64_t rx_1_to_64_packets;
> uint64_t rx_65_to_127_packets;
> diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
> index 3498b32..6c2eb38 100644
> --- a/lib/netdev-dpdk.c
> +++ b/lib/netdev-dpdk.c
> @@ -2124,6 +2124,7 @@ netdev_dpdk_vhost_update_rx_counters(struct
> netdev_stats *stats,
>
> stats->rx_packets += count;
> stats->rx_dropped += dropped;
> +stats->rx_qos_drops += dropped;
> for (i = 0; i < count; i++) {
> packet = packets[i];
> packet_size = dp_packet_size(packet);
> @@ -2236,6 +2237,7 @@ netdev_dpdk_rxq_recv(struct netdev_rxq *rxq, struct
> dp_packet_batch *batch,
> if (OVS_UNLIKELY(dropped)) {
> rte_spinlock_lock(>stats_lock);
> dev->stats.rx_dropped += dropped;
> +dev->stats.rx_qos_drops += dropped;
> rte_spinlock_unlock(>stats_lock);
> }
>
> @@ -2319,6 +2321,9 @@ __netdev_dpdk_vhost_send(struct netdev *netdev, int qid,
> struct rte_mbuf **cur_pkts = (struct rte_mbuf **) pkts;
> unsigned int total_pkts = cnt;
> unsigned int dropped = 0;
> +unsigned int mtu_drops;
> +unsigned int qos_drops;
> +unsigned int qfull_drops;
> int i, retries = 0;
> int vid = netdev_dpdk_get_vid(dev);
>
> @@ -2335,9 +2340,11 @@ __netdev_dpdk_vhost_send(struct netdev *netdev, int
> qid,
There can be other drops earlier in this function, should they be logged
also?
> rte_spinlock_lock(>tx_q[qid].tx_lock);
>
> cnt = netdev_dpdk_filter_packet_len(dev, cur_pkts, cnt);
> +mtu_drops = total_pkts - cnt;
> +qos_drops = cnt;
> /* Check has QoS has been configured for the netdev */
> cnt = netdev_dpdk_qos_run(dev, cur_pkts, cnt, true);
> -dropped = total_pkts - cnt;
> +qos_drops -= cnt;
>
> do {
> int vhost_qid = qid * VIRTIO_QNUM + VIRTIO_RXQ;
> @@ -2357,9 +2364,14 @@ __netdev_dpdk_vhost_send(struct netdev *netdev, int
> qid,
>
> rte_spinlock_unlock(>tx_q[qid].tx_lock);
>
> +qfull_drops = cnt;
> +dropped = mtu_drops + qos_drops + qfull_drops;
> rte_spinlock_lock(>stats_lock);
> netdev_dpdk_vhost_update_tx_counters(>stats, pkts, total_pkts,
> -
Re: [ovs-dev] [PATCHv11] netdev-afxdp: add new netdev type for AF_XDP.
On 18 Jun 2019, at 12:17, Ilya Maximets wrote:
On 18.06.2019 12:45, Eelco Chaudron wrote:
On 17 Jun 2019, at 22:32, William Tu wrote:
1000,463875,419996,402010
However I can not restart OVS (see other email on how I restart),
even if I clear the XDP programs before a restart it fails, and
cores.
The only way to recover is to reboot the box and start from scratch:
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x7f455919a9b5 in xsk_clear_bpf_maps (xsk=0x21) at xsk.c:462
462 bpf_map_update_elem(xsk->qidconf_map_fd,
>queue_id, , 0);
[Current thread is 1 (Thread 0x7f4559f1c000 (LWP 4898))]
Missing separate debuginfos, use: dnf debuginfo-install
elfutils-libelf-0.174-6.el8.x86_64 glibc-2.28-42.el8_0.1.x86_64
libatomic-8.2.1-3.5.el8.x86_64 libcap-ng-0.7.9-4.el8.x86_64
numactl-libs-2.0.12-2.el8.x86_64 openssl-libs-1.1.1-8.el8.x86_64
zlib-1.2.11-10.el8.x86_64
(gdb) bt
#0 0x7f455919a9b5 in xsk_clear_bpf_maps (xsk=0x21) at xsk.c:462
#1 0x7f455919b278 in xsk_socket__delete (xsk=0x21) at xsk.c:711
#2 0x009b3af1 in xsk_destroy (xsk_info=) at
lib/netdev-afxdp.c:313
#3 xsk_destroy_all (netdev=0x1df49a0) at lib/netdev-afxdp.c:313
#4 0x009b4fe9 in netdev_afxdp_destruct (netdev_=0x1df49a0)
at lib/netdev-afxdp.c:845
#5 0x00906e53 in netdev_unref (dev=0x1df49a0) at
lib/netdev.c:573
#6 0x008739b1 in iface_do_create (errp=0x7ffe4fc5b588,
netdevp=0x7ffe4fc5b580, ofp_portp=0x7ffe4fc5b578,
iface_cfg=0x1cde5d0, br=0x1ce1690) at vswitchd/bridge.c:1825
#7 iface_create (port_cfg=0x1cb3690, iface_cfg=0x1cde5d0,
br=0x1ce1690) at vswitchd/bridge.c:1848
#8 bridge_add_ports__ (br=br@entry=0x1ce1690,
wanted_ports=wanted_ports@entry=0x1ce1770,
with_requested_port=with_requested_port@entry=false) at
vswitchd/bridge.c:936
#9 0x00875ef7 in bridge_add_ports (wanted_ports=0x1ce1770,
br=0x1ce1690) at vswitchd/bridge.c:952
#10 bridge_reconfigure (ovs_cfg=ovs_cfg@entry=0x1cb4b90) at
vswitchd/bridge.c:666
#11 0x00879521 in bridge_run () at vswitchd/bridge.c:3043
#12 0x004ef545 in main (argc=, argv=out>) at vswitchd/ovs-vswitchd.c:127
Jun 18 03:52:06 wsfd-netdev76.ntdv.lab.eng.bos.redhat.com
ovs-vswitchd[5861]: ovs|00051|netdev_afxdp|ERR|xsk_socket__create
failed (Device or resource busy) mode: SKB qid: 0
Jun 18 03:52:06 wsfd-netdev76.ntdv.lab.eng.bos.redhat.com
ovs-vswitchd[5861]: ovs|00052|netdev_afxdp|ERR|failed to create
AF_XDP socket on queue 0
Jun 18 03:52:06 wsfd-netdev76.ntdv.lab.eng.bos.redhat.com
ovs-vswitchd[5861]: ovs|00055|netdev_afxdp|ERR|AF_XDP device tapVM
reconfig fails
Jun 18 03:52:06 wsfd-netdev76.ntdv.lab.eng.bos.redhat.com
ovs-vswitchd[5861]: ovs|00056|dpif_netdev|ERR|Failed to set interface
tapVM new configuration
Jun 18 03:52:06 wsfd-netdev76.ntdv.lab.eng.bos.redhat.com
ovs-vswitchd[5861]: ovs|00062|netdev_afxdp|ERR|xsk_socket__create
failed (Device or resource busy) mode: DRV qid: 0
Jun 18 03:52:06 wsfd-netdev76.ntdv.lab.eng.bos.redhat.com
ovs-vswitchd[5861]: ovs|00063|netdev_afxdp|ERR|failed to create
AF_XDP socket on queue 0
Jun 18 03:52:06 wsfd-netdev76.ntdv.lab.eng.bos.redhat.com
ovs-vswitchd[5861]: ovs|00066|netdev_afxdp|ERR|AF_XDP device eno1
reconfig fails
Jun 18 03:52:06 wsfd-netdev76.ntdv.lab.eng.bos.redhat.com
ovs-vswitchd[5861]: ovs|00067|dpif_netdev|ERR|Failed to set interface
eno1 new configuration
Jun 18 03:52:06 wsfd-netdev76.ntdv.lab.eng.bos.redhat.com kernel:
ovs-vswitchd[5861]: segfault at 123 ip 009b3afd sp
7954a770 error 4 in ovs-vswitchd[40+899000]
I guess, this crash caused by trying to destroy unallocated queue.
Following change could help:
---
diff --git a/lib/netdev-afxdp.c b/lib/netdev-afxdp.c
index a6543e8f5..6e1431dce 100644
--- a/lib/netdev-afxdp.c
+++ b/lib/netdev-afxdp.c
@@ -249,7 +249,7 @@ xsk_configure_all(struct netdev *netdev)
ifindex = linux_get_ifindex(netdev_get_name(netdev));
n_rxq = netdev_n_rxq(netdev);
-dev->xsks = xmalloc(n_rxq * sizeof(struct xsk_socket_info *));
+dev->xsks = xzalloc(n_rxq * sizeof(struct xsk_socket_info *));
/* configure each queue */
for (i = 0; i < n_rxq; i++) {
---
This should prevent OVS from crash, however, I don't know why socket
creation fails in your case.
I know William is preparing a v12, so will do some more testing once
it’s out, and update my kernel to the latest bpf-next just to make
sure I’m not running into a known/fixed issue.
//Eelco
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCHv11] netdev-afxdp: add new netdev type for AF_XDP.
On 18.06.2019 12:45, Eelco Chaudron wrote:
>
>
> On 17 Jun 2019, at 22:32, William Tu wrote:
>
>> On Mon, Jun 17, 2019 at 11:23 AM William Tu wrote:
>>>
>>> Hi Eelco,
>>>
>>> On Mon, Jun 17, 2019 at 3:12 AM Eelco Chaudron wrote:
Hi William,
See below parts of an offline email discussion I had with Magnus before,
and some research I did in the end, which explains that by design you
might not get all the descriptors ready.
>>>
>>> I think it's different issues. The behavior you described is a hickup
>>> waiting
>>> for queuing 16 rx packets. Here, at the afxdp_complete_tx, the
>>> xsk_ring_cons__peek
>>> returns descs that already been released, causing ovs push more elems and
>>> thus
>>> crash.
>>>
Hope this helps change your design…
In addition, the Point to Point test is working with you change,
however, the PVP test is still failing due to buffer starvation (see my
comments in Patchv8 for a possible cause).
>>> Thanks, looking back v8
>>> https://patchwork.ozlabs.org/patch/1097740/
>>> Hopefully next version will fix this issue.
>>>
Also on OVS restart system crashes in the following part:
#0 netdev_afxdp_rxq_recv (rxq_=0x173c080, batch=0x7fe1397f80d0,
qfill=0x0) at lib/netdev-afxdp.c:583
#1 0x00907f21 in netdev_rxq_recv (rx=,
batch=batch@entry=0x7fe1397f80d0, qfill=) at
lib/netdev.c:710
#2 0x008dd1c3 in dp_netdev_process_rxq_port
(pmd=pmd@entry=0x175d990, rxq=0x175a460, port_no=2) at
lib/dpif-netdev.c:4257
#3 0x008dd63d in pmd_thread_main (f_=) at
lib/dpif-netdev.c:5449
#4 0x0095e94d in ovsthread_wrapper (aux_=) at
lib/ovs-thread.c:352
#5 0x7fe1633872de in start_thread () from /lib64/libpthread.so.0
#6 0x7fe162b2ca63 in clone () from /lib64/libc.so.6
>>> How do you restart the system? So I have two afxdp port
>>> Port "eth3"
>>> Interface "eth3"
>>> type: afxdp
>>> options: {n_rxq="1", xdpmode=drv}
>>> Port "eth5"
>>> Interface "eth5"
>>> type: afxdp
>>> options: {n_rxq="1", xdpmode=drv}
>>>
>>> I tested using
>>> # ovs-vsctl del-port eth3
>>> # ovs-vsctl del-port eth5
>>> # ovs-vsctl del-br br0
>>> # ovs-appctl -t ovs-vswitchd exit
>>> Looks ok.
>>>
>>>
>>>
> This means, that if you rely on (the naive :-)) code in the sample
> application, you can endup in a situation where you can receive from
> the
> Rx ring, but not post to the fill ring.
>
> So, the reason for the 16 packet hickup is as following:
>
> 1. Userland: The fill ring is completely filled.
> 2. Kernel: One packet is received, one entry picked from the fill
> ring,
> but the consumer pointer is not bumped, and packet is placed on the
> Rx ring.
> 3. Userland: One packet is picked from the Rx ring.
> 4. Userland: Tries to put an entry on fill ring. The fill ring is
> full,
> so userland spins.
> 5. Kernel: When 16 packets has been picked from the fill ring the
> consumer ptr is released.
> 6. Userland: Exists the while loop.
>>>
>>> Based on the above, there is no starvation problem here if there are more
>>> than 16 packets, correct? And at step 4, we can skip spinning and try to
>>> process more rx ring.
>>>
>>> For next version, I will first check the fill ring by using
>>> xsk_prod_nb_free(),
>>> to avoid the step 4.
>>>
>>> Thanks
>>> William
>>
>> Hi Eelco,
>>
>> I have some fixes with commit "prepare for v12" at
>> https://github.com/williamtu/ovs-ebpf/commits/afxdp-v11
>>
>> I tested PVP and it works ok (using tap and also veth namespaces)
>> Can you give it a try?
>
> The PVP test seems to work fine however after a while it stops forwarding:
>
> $ ovs-ofctl dump-flows ovs_pvp_br0
> cookie=0x0, duration=8.510s, table=0, n_packets=1, n_bytes=1020,
> in_port=eno1 actions=output:tapVM
> cookie=0x0, duration=8.504s, table=0, n_packets=1, n_bytes=252,
> in_port=tapVM actions=output:eno1
>
> Results:
>
> "Physical port, ""eno1"", speed 10 Gbit/s, traffic rate 100%"
> "Physical to Virtual to Physical test, L3 flows[port redirect]"
> ,Packet size
> Number of flows,64,256,1024
> 10,13448,131687,0
> 100,596,0,0
> 1000,596,0,0
>
> Rather low compared to the kernel, note the above is using a single queue:
>
> "Physical port, ""eno1"", speed 10 Gbit/s, traffic rate 100%"
> "Physical to Virtual to Physical test, L3 flows[port redirect]"
> ,Packet size
> Number of flows,64,256,1024
> 10,502411,451579,421558
> 100,525439,440637,422051
> 1000,463875,419996,402010
>
> However I can not restart OVS (see other email on how I restart), even if I
> clear the XDP programs before a restart it fails, and cores.
> The only way to recover is to reboot the box and start from scratch:
>
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0
Re: [ovs-dev] [PATCHv11] netdev-afxdp: add new netdev type for AF_XDP.
On 17 Jun 2019, at 22:32, William Tu wrote:
On Mon, Jun 17, 2019 at 11:23 AM William Tu
wrote:
Hi Eelco,
On Mon, Jun 17, 2019 at 3:12 AM Eelco Chaudron
wrote:
Hi William,
See below parts of an offline email discussion I had with Magnus
before,
and some research I did in the end, which explains that by design
you
might not get all the descriptors ready.
I think it's different issues. The behavior you described is a hickup
waiting
for queuing 16 rx packets. Here, at the afxdp_complete_tx, the
xsk_ring_cons__peek
returns descs that already been released, causing ovs push more elems
and thus
crash.
Hope this helps change your design…
In addition, the Point to Point test is working with you change,
however, the PVP test is still failing due to buffer starvation (see
my
comments in Patchv8 for a possible cause).
Thanks, looking back v8
https://patchwork.ozlabs.org/patch/1097740/
Hopefully next version will fix this issue.
Also on OVS restart system crashes in the following part:
#0 netdev_afxdp_rxq_recv (rxq_=0x173c080, batch=0x7fe1397f80d0,
qfill=0x0) at lib/netdev-afxdp.c:583
#1 0x00907f21 in netdev_rxq_recv (rx=,
batch=batch@entry=0x7fe1397f80d0, qfill=) at
lib/netdev.c:710
#2 0x008dd1c3 in dp_netdev_process_rxq_port
(pmd=pmd@entry=0x175d990, rxq=0x175a460, port_no=2) at
lib/dpif-netdev.c:4257
#3 0x008dd63d in pmd_thread_main (f_=) at
lib/dpif-netdev.c:5449
#4 0x0095e94d in ovsthread_wrapper (aux_=)
at
lib/ovs-thread.c:352
#5 0x7fe1633872de in start_thread () from
/lib64/libpthread.so.0
#6 0x7fe162b2ca63 in clone () from /lib64/libc.so.6
How do you restart the system? So I have two afxdp port
Port "eth3"
Interface "eth3"
type: afxdp
options: {n_rxq="1", xdpmode=drv}
Port "eth5"
Interface "eth5"
type: afxdp
options: {n_rxq="1", xdpmode=drv}
I tested using
# ovs-vsctl del-port eth3
# ovs-vsctl del-port eth5
# ovs-vsctl del-br br0
# ovs-appctl -t ovs-vswitchd exit
Looks ok.
This means, that if you rely on (the naive :-)) code in the sample
application, you can endup in a situation where you can receive
from
the
Rx ring, but not post to the fill ring.
So, the reason for the 16 packet hickup is as following:
1. Userland: The fill ring is completely filled.
2. Kernel: One packet is received, one entry picked from the fill
ring,
but the consumer pointer is not bumped, and packet is placed on
the
Rx ring.
3. Userland: One packet is picked from the Rx ring.
4. Userland: Tries to put an entry on fill ring. The fill ring is
full,
so userland spins.
5. Kernel: When 16 packets has been picked from the fill ring the
consumer ptr is released.
6. Userland: Exists the while loop.
Based on the above, there is no starvation problem here if there are
more
than 16 packets, correct? And at step 4, we can skip spinning and try
to
process more rx ring.
For next version, I will first check the fill ring by using
xsk_prod_nb_free(),
to avoid the step 4.
Thanks
William
Hi Eelco,
I have some fixes with commit "prepare for v12" at
https://github.com/williamtu/ovs-ebpf/commits/afxdp-v11
I tested PVP and it works ok (using tap and also veth namespaces)
Can you give it a try?
The PVP test seems to work fine however after a while it stops
forwarding:
$ ovs-ofctl dump-flows ovs_pvp_br0
cookie=0x0, duration=8.510s, table=0, n_packets=1, n_bytes=1020,
in_port=eno1 actions=output:tapVM
cookie=0x0, duration=8.504s, table=0, n_packets=1, n_bytes=252,
in_port=tapVM actions=output:eno1
Results:
"Physical port, ""eno1"", speed 10 Gbit/s, traffic rate 100%"
"Physical to Virtual to Physical test, L3 flows[port redirect]"
,Packet size
Number of flows,64,256,1024
10,13448,131687,0
100,596,0,0
1000,596,0,0
Rather low compared to the kernel, note the above is using a single
queue:
"Physical port, ""eno1"", speed 10 Gbit/s, traffic rate 100%"
"Physical to Virtual to Physical test, L3 flows[port redirect]"
,Packet size
Number of flows,64,256,1024
10,502411,451579,421558
100,525439,440637,422051
1000,463875,419996,402010
However I can not restart OVS (see other email on how I restart), even
if I clear the XDP programs before a restart it fails, and cores.
The only way to recover is to reboot the box and start from scratch:
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x7f455919a9b5 in xsk_clear_bpf_maps (xsk=0x21) at xsk.c:462
462 bpf_map_update_elem(xsk->qidconf_map_fd, >queue_id, ,
0);
[Current thread is 1 (Thread 0x7f4559f1c000 (LWP 4898))]
Missing separate debuginfos, use: dnf debuginfo-install
elfutils-libelf-0.174-6.el8.x86_64 glibc-2.28-42.el8_0.1.x86_64
libatomic-8.2.1-3.5.el8.x86_64 libcap-ng-0.7.9-4.el8.x86_64
numactl-libs-2.0.12-2.el8.x86_64 openssl-libs-1.1.1-8.el8.x86_64
zlib-1.2.11-10.el8.x86_64
(gdb) bt
#0 0x7f455919a9b5 in xsk_clear_bpf_maps (xsk=0x21) at
Re: [ovs-dev] [PATCHv11] netdev-afxdp: add new netdev type for AF_XDP.
On 17 Jun 2019, at 20:23, William Tu wrote:
Hi Eelco,
On Mon, Jun 17, 2019 at 3:12 AM Eelco Chaudron
wrote:
Hi William,
See below parts of an offline email discussion I had with Magnus
before,
and some research I did in the end, which explains that by design you
might not get all the descriptors ready.
I think it's different issues. The behavior you described is a hickup
waiting
for queuing 16 rx packets. Here, at the afxdp_complete_tx, the
xsk_ring_cons__peek
returns descs that already been released, causing ovs push more elems
and thus
crash.
You are right did not read it thoroughly… Looks like a bug to me,
after __release() I would assume it will not return the same elements in
__peek().
Hope this helps change your design…
In addition, the Point to Point test is working with you change,
however, the PVP test is still failing due to buffer starvation (see
my
comments in Patchv8 for a possible cause).
Thanks, looking back v8
https://patchwork.ozlabs.org/patch/1097740/
Hopefully next version will fix this issue.
Also on OVS restart system crashes in the following part:
#0 netdev_afxdp_rxq_recv (rxq_=0x173c080, batch=0x7fe1397f80d0,
qfill=0x0) at lib/netdev-afxdp.c:583
#1 0x00907f21 in netdev_rxq_recv (rx=,
batch=batch@entry=0x7fe1397f80d0, qfill=) at
lib/netdev.c:710
#2 0x008dd1c3 in dp_netdev_process_rxq_port
(pmd=pmd@entry=0x175d990, rxq=0x175a460, port_no=2) at
lib/dpif-netdev.c:4257
#3 0x008dd63d in pmd_thread_main (f_=) at
lib/dpif-netdev.c:5449
#4 0x0095e94d in ovsthread_wrapper (aux_=) at
lib/ovs-thread.c:352
#5 0x7fe1633872de in start_thread () from /lib64/libpthread.so.0
#6 0x7fe162b2ca63 in clone () from /lib64/libc.so.6
How do you restart the system? So I have two afxdp port
Port "eth3"
Interface "eth3"
type: afxdp
options: {n_rxq="1", xdpmode=drv}
Port "eth5"
Interface "eth5"
type: afxdp
options: {n_rxq="1", xdpmode=drv}
I tested using
# ovs-vsctl del-port eth3
# ovs-vsctl del-port eth5
# ovs-vsctl del-br br0
# ovs-appctl -t ovs-vswitchd exit
Looks ok.
I’m using an RHEL7 instance and use systemd to restart openvswitch
with “systemctl restart openvswitch”.
It uses ovs-ctl to stat/stop, see here for some details:
https://github.com/openvswitch/ovs/blob/master/rhel/usr_lib_systemd_system_ovs-vswitchd.service.in
This means, that if you rely on (the naive :-)) code in the sample
application, you can endup in a situation where you can receive from
the
Rx ring, but not post to the fill ring.
So, the reason for the 16 packet hickup is as following:
1. Userland: The fill ring is completely filled.
2. Kernel: One packet is received, one entry picked from the fill
ring,
but the consumer pointer is not bumped, and packet is placed on
the
Rx ring.
3. Userland: One packet is picked from the Rx ring.
4. Userland: Tries to put an entry on fill ring. The fill ring is
full,
so userland spins.
5. Kernel: When 16 packets has been picked from the fill ring the
consumer ptr is released.
6. Userland: Exists the while loop.
Based on the above, there is no starvation problem here if there are
more
than 16 packets, correct? And at step 4, we can skip spinning and try
to
process more rx ring.
For next version, I will first check the fill ring by using
xsk_prod_nb_free(),
to avoid the step 4.
Yes, a __free() check here will skip this problem. I was running a
single ping only test and it would spin forever…
Thanks
William
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] Диафильмы для детей в цифровом формате - уникальная коллекция в отличном качестве. 13_05_2019 02_03 198707
ДЕТСКИЕ ДИАФИЛЬМЫ Каждый из нас бережно хранит в своем сердце воспоминания детства. Радостные или грустные, светлые или полные горечи, они служат как бы мостиком, который связывает нас сегодняшних, взрослых и солидных, с теми маленькими детьми, которыми мы были когда-то. Иногда, испытывая ностальгию по ушедшему детству, мы достаем эти воспоминания из глубин своей памяти, чтобы вернуться хотя бы на секунду в то беззаботное время, свободное от наших нынешних проблем и забот. Для многих из нас такими яркими воспоминаниями могут стать диафильмы, которые мы смотрели в детстве. Тихое гудение проектора-фильмоскопа и яркий луч, превращающий белую простыню на стене в волшебный экран, на котором сменяют друг друга цветные картинки… Все это навсегда остается в памяти ребенка. Помните свое настроение в тот момент? Радость и нетерпение, пока старшие настраивают объектив и заряжают пленку с диафильмом в проектор, ваш восторг в ту секунду, когда на стене появляется первый кадр, и начинается сказка… Нашу теперешнюю жизнь уже сложно представить без телевизоров, DVD-проигрывателей, компьютеров и прочих чудес техники, но они не смогут вытеснить из вашего сердца эту чистую детскую радость от цветной сказки, нарисованной лучом света на белой простыне. И пускай прошло уже столько лет, мы предлагаем вам и вашим детям попробовать снова пережить те непередаваемые ощущения. Вы удивитесь, насколько легко эти забытые детские чувства могут охватить вас, вернуть вас, казалось бы, в безвозвратно ушедшее прошлое. Кроме того, просмотр диафильмов — это ведь еще и прекрасный способ привить ребенку вкус, поскольку рисовали лучшие художники Союза. Не лишнем будет умение излагать мысли, поскольку можно остановиться в любом месте и обсудить с ребёнком увиденное. Великолепная возможность обучить чтению и всестороннему развитию поскольку в коллекцию входит огромное количество сказок и историй, от Древнего Рима до фантастики и космоса. Дарите своим детям волшебство, тепло и радость взаимного общения, как когда-то его подарили всем нам наши родители, когда деревья были большими и не было видео и интернета. ! Список диафильмов вошедших в коллекцию вы можете увидеть в прикреплённом к письму файле ! Коллекция состоит из 2133 диафильмов в формате JPEG. Записана на внешний USB накопитель (флешка). Проблем с воспроизведением не возникнет, можно смотреть на компьютере, планшете, смартфоне, телевизоре и т.д. Запись на внешний USB накопитель имеет ряд преимуществ в сравнении с обычными DVD дисками, USB накопитель гораздо легче, занимает меньше места, обладает высокой надёжностью сохранности записей, а это значит, что наша коллекция будет радовать Вас много лет. Мы гарантируем отличное качество всех записей. На самом носителе создана продуманная структура, все записи разнесены по каталогам, имеются плейлисты, прописаны теги, а также полный список вошедших записей, поэтому проблем с поиском и навигацией не возникнет. Стоимость коллекции на внешнем USB накопителе — 6500 (Шесть Тысяч Пятьсот) Рублей. Продаются только вместе. Доставка включена в стоимость. Доставка только почтой по всей России, сроки 7-14 суток с момента отправки. Оплата в момент получения заказа на почте наложенным платежом. У нас нет курьерской доставки — только почтой, в том числе и по Москве. Для оформления заказа просьба не забывать указывать: --- Ваш почтовый индекс (пишите правильный индекс — это ускорит доставку); --- Ваш город и точный адрес (название улицы, номер дома и номер квартиры); --- Ф.И.О. получателя и ОБЯЗАТЕЛЬНО номер контактного телефона (лучше сотовый); Заказы\вопросы направляйте по адресу: diafi...@cwhflash.ru Мы очень ответственно относимся к качеству нашего товара, поэтому перед отправкой всё дополнительно проверяется, как следствие отправка бракованной продукции сведена к нулю. Товар упаковывается в специальный ударостойкий материал, что в значительной степени уменьшает риск повреждения при транспортировке. Если вдруг с полученным товаром возникнут проблемы, то все наши покупатели всегда могут рассчитывать на квалифицированную техническую поддержку. Мы никогда не отказываемся от гарантийных обязательств, в случае проблемы Вы можете рассчитывать на замену, почтовые расходы мы берём на себя. По вашему желанию, данная коллекция может быть записана на DVD диски. Для записи используются надёжные DVD диски со специальным покрытием, которое повышает устойчивость диска к механическим повреждениям, таким как трещины и царапины, а это значит, что наша коллекция будет радовать Вас много лет. Коллекция упакована в пластиковые боксы (slim-dvd), имеет красивые и продуманные обложки, с обратной стороны которых указан список вошедших на каждый диск диафильмов и другая полезная информация, поэтому проблем с поиском и навигацией не возникнет. Если хотите приобрести коллекцию, записанную на DVD дисках, то в этом случае просьба сообщить нам об этом в своей заявке, цена прежняя, как у версии на внешнем USB накопителе (флешка)
[ovs-dev] test
Dear, dev ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v2] Detailed packet drop statistics per dpdk and vhostuser ports
Please consider this as a gentle remainder.
Thanks & Regards,
Sriram.
-Original Message-
From: Sriram Vatala
Sent: 14 June 2019 19:08
To: ovs-dev@openvswitch.org
Cc: Sriram Vatala
Subject: [PATCH v2] Detailed packet drop statistics per dpdk and vhostuser
ports
OVS may be unable to transmit packets for multiple reasons and today there
is a single counter to track packets dropped due to any of those reasons.
The most common reason is that a VM is unable to read packets fast enough
causing the vhostuser port transmit queue on the OVS side to become full.
This manifests as a problem with VNFs not receiving all packets. Having a
separate drop counter to track packets dropped because the transmit queue is
full will clearly indicate that the problem is on the VM side and not in
OVS. Similarly maintaining separate counters for all possible drops helps in
indicating sensible cause for packet drops.
This patch adds counters to track packets dropped due to all possible
reasons and these counters are displayed along with other stats in
"ovs-vsctl get interface statistics"
command. The detailed stats will be available for both dpdk and vhostuser
ports.
Following are the details of the new counters :
tx_qfull_drops : These are the packets dropped due to transmit queue
overrun.
tx_mtu_exceeded_drops : These are the packets dropped due to MTU mismatch
(i.e Pkt len > Max Dev MTU).
tx_qos_drops/rx_qos_drops : These are the packets dropped due to
transmission/reception rate exceeding the configured Egress/Ingress policer
rate on the interface.
Signed-off-by: Sriram Vatala
---
include/openvswitch/netdev.h | 8
lib/netdev-dpdk.c | 49
++
utilities/bugtool/automake.mk | 3 +-
utilities/bugtool/ovs-bugtool-get-iface-stats | 25 +++
.../bugtool/plugins/network-status/openvswitch.xml | 3 ++
vswitchd/bridge.c | 6 ++-
6 files changed, 85 insertions(+), 9 deletions(-) create mode 100755
utilities/bugtool/ovs-bugtool-get-iface-stats
diff --git a/include/openvswitch/netdev.h b/include/openvswitch/netdev.h
index 0c10f7b..69480a4 100644
--- a/include/openvswitch/netdev.h
+++ b/include/openvswitch/netdev.h
@@ -61,6 +61,14 @@ struct netdev_stats {
uint64_t tx_heartbeat_errors;
uint64_t tx_window_errors;
+/* Detailed receive drops. */
+uint64_t rx_qos_drops;
+
+/* Detailed transmit drops. */
+uint64_t tx_qfull_drops;
+uint64_t tx_qos_drops;
+uint64_t tx_mtu_drops;
+
/* Extended statistics based on RFC2819. */
uint64_t rx_1_to_64_packets;
uint64_t rx_65_to_127_packets;
diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c index 3498b32..6c2eb38
100644
--- a/lib/netdev-dpdk.c
+++ b/lib/netdev-dpdk.c
@@ -2124,6 +2124,7 @@ netdev_dpdk_vhost_update_rx_counters(struct
netdev_stats *stats,
stats->rx_packets += count;
stats->rx_dropped += dropped;
+stats->rx_qos_drops += dropped;
for (i = 0; i < count; i++) {
packet = packets[i];
packet_size = dp_packet_size(packet); @@ -2236,6 +2237,7 @@
netdev_dpdk_rxq_recv(struct netdev_rxq *rxq, struct dp_packet_batch *batch,
if (OVS_UNLIKELY(dropped)) {
rte_spinlock_lock(>stats_lock);
dev->stats.rx_dropped += dropped;
+dev->stats.rx_qos_drops += dropped;
rte_spinlock_unlock(>stats_lock);
}
@@ -2319,6 +2321,9 @@ __netdev_dpdk_vhost_send(struct netdev *netdev, int
qid,
struct rte_mbuf **cur_pkts = (struct rte_mbuf **) pkts;
unsigned int total_pkts = cnt;
unsigned int dropped = 0;
+unsigned int mtu_drops;
+unsigned int qos_drops;
+unsigned int qfull_drops;
int i, retries = 0;
int vid = netdev_dpdk_get_vid(dev);
@@ -2335,9 +2340,11 @@ __netdev_dpdk_vhost_send(struct netdev *netdev, int
qid,
rte_spinlock_lock(>tx_q[qid].tx_lock);
cnt = netdev_dpdk_filter_packet_len(dev, cur_pkts, cnt);
+mtu_drops = total_pkts - cnt;
+qos_drops = cnt;
/* Check has QoS has been configured for the netdev */
cnt = netdev_dpdk_qos_run(dev, cur_pkts, cnt, true);
-dropped = total_pkts - cnt;
+qos_drops -= cnt;
do {
int vhost_qid = qid * VIRTIO_QNUM + VIRTIO_RXQ; @@ -2357,9 +2364,14
@@ __netdev_dpdk_vhost_send(struct netdev *netdev, int qid,
rte_spinlock_unlock(>tx_q[qid].tx_lock);
+qfull_drops = cnt;
+dropped = mtu_drops + qos_drops + qfull_drops;
rte_spinlock_lock(>stats_lock);
netdev_dpdk_vhost_update_tx_counters(>stats, pkts, total_pkts,
- cnt + dropped);
+ dropped);
+dev->stats.tx_mtu_drops += mtu_drops;
+dev->stats.tx_qos_drops += qos_drops;
+dev->stats.tx_qfull_drops += qfull_drops;
rte_spinlock_unlock(>stats_lock);
out:
@@ -2384,12 +2396,15 @@ dpdk_do_tx_copy(struct netdev *netdev, int qid,
struct
