Date: Sun, 7 Jun 2020 09:48:52 +0200 From: Vincenzo Maffione <vmaffione@freebsd.org> To: Anthony Arnaud <antho.arnaudisce@gmail.com> Cc: Luigi Rizzo <rizzo@iet.unipi.it>, "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> Subject: Re: Netmap - Vale switch - tcp problem Message-ID: <CA%2B_eA9jiJnghcO8Vej3FdZ1y5oO0%2Bmvy=EJEAioB6PMywRyOyA@mail.gmail.com> In-Reply-To: <CAGCUUMEOPQ1QHXvokvLQPy5dxpoYtUZ%2B0xZbXcKjSCVCQhQfFw@mail.gmail.com> References: <CAGCUUMGxxiv8j-W3S8Gs1g=ZbDLnU8_Hv6SVMCpmnrRXPNsUTA@mail.gmail.com> <CA%2BhQ2%2BhfDvKv8q%2BjUB-mv_TaUTHfTPabx-qem-0=PW3vu8Br=A@mail.gmail.com> <CAGCUUMHwRghU3AMgKhQNrUs248y=NaGFN2Fm-f4khqhRsWn-qg@mail.gmail.com> <CA%2B_eA9iukqVoDZFyyW2qEZ2OHfE9=fUj070uUXcYmrXt67mwqw@mail.gmail.com> <CAGCUUMG7HG%2B8X89AYrhQ4dh6-equsvOLNyn_3sNU8h55PjPv9A@mail.gmail.com> <CA%2B_eA9j9zTM2JwCeMy6FmJQJmorVzXns2ijFgjuXa%2BrRQH400A@mail.gmail.com> <CAGCUUMEtuk4GW-7O%2B_XNcsh%2Bfrzu2O8ZBR_7SDQ-ir=L-dk0rw@mail.gmail.com> <CA%2B_eA9h%2B-z6mGCERK2_3fqCforqy5f8-caNsDKF0r1GF%2BkOfSQ@mail.gmail.com> <CA%2B_eA9hupv0JG7Q_LXUg7-StcEr=buLbBcJdvm1WRFy5PYqPUQ@mail.gmail.com> <CAGCUUMGJ2XSXFWMqL9TfCH7d6fTScF4s3u%2BwkbC1sqtPyFvqeA@mail.gmail.com> <CA%2B_eA9hi3FECs_u%2Bx_051HHxJqAggLx7KcbL_N5nvMXTPVc-vg@mail.gmail.com> <CAGCUUMEOPQ1QHXvokvLQPy5dxpoYtUZ%2B0xZbXcKjSCVCQhQfFw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Il giorno sab 6 giu 2020 alle ore 20:32 Anthony Arnaud < antho.arnaudisce@gmail.com> ha scritto: > This works!! > A good news! > It works even if I connect the nic to vale switch directly from ssh, the > connection does not drop like before your patch. > Yes, connecting the vtnet0 to the vale switch it's what I meant. > Can you list the steps to setup the bridge in your tests? I thing > "ifconfig bridge create" etc. > I was doing my tests on a Linux host (KVM hypervisor), but it should be the same if you run on FreeBSD. The steps are: # ifconfig bridge0 create # ifconfig bridge0 up 192.168.1.1/24 # ifconfig tap0 create # ifconfig tap0 up # ifconfig bridge0 addm tap0 And then run your VM in such a way that your vtnet0 is backed by tap0. It's basically the same instructions you find here: https://www.freebsd.org/doc/handbook/virtualization-host-bhyve.html Now I have to understand why it doesn't work in my previous case. > At this point I think if you still don't see TCP traffic you are likely to have some misconfiguration, rather than a VALE/vtnet issue. It may be useful to know that netmap has an intercept mechanism, "netmap monitor ports", that you can use to sniff on any netmap port, while the netmap port is being used by another netmap application. For instance, if you run # pkt-gen -XX -i netmap:vtnet0/r you will sniff all the packets that are being received on the vtnet0 port. Otherwise you can sniff packets being transmitted: # pkt-gen -XX -i netmap:vtnet0/t The same goes for VALE ports: # pkt-gen -XX -i vale0:1/r This is very similar to tcpdump (although pkt-gen does not do packet decode and pretty printing). Cheers, VIncenzo > Thanks, > Antho > > Il giorno sab 6 giu 2020 alle ore 09:52 Vincenzo Maffione < > vmaffione@freebsd.org> ha scritto: > >> >> >> Il giorno ven 5 giu 2020 alle ore 18:16 Anthony Arnaud < >> antho.arnaudisce@gmail.com> ha scritto: >> >>> Hi Vincenzo, >>> Thank you for your answers. >>> I upgraded a guest machine in proxmox env to FreeBSD 13.0-CURRENT #0 >>> r361830. >>> After that I compiled the tools as usual from /src/tools/tools/netmap >>> I configured 2 NIC vtnet >>> >>> vtnet0 with an ip 192.168.1.x >>> vtnet1 without ip and csum disabled as mirror of vtnet0 (using Open >>> vSwitch) >>> Tcp traffic is generated by an ssh connection from my host to guest >>> machine. >>> >> >> Not clear where you run OVS. In the host or in the guest? >> >> >>> "tcpdump -i vtnet1 tcp": at each keypress in ssh shell connected to >>> 192.168.1.x I see few tcp packet sniffed in guest machine. >>> But if I attach vtnet1 to vale switch, tcpdump no longer works as >>> before. No tcp traffic is shown. >>> Can I perform any other test about this? >>> >> >> First, have you tried to leave vtnet1 alone and try: >> >> # ifconfig vtnet0 up 192.168.1.x -txcsum -rxcsum -tso4 -tso6 >> # vale-ctl -h vale0:vtnet0 >> and verified that you can ssh into 192.168.1.x from the host? >> >> At least you verify that the vale-ctl -h works also on your enivironment. >> >> Cheers, >> Vincenzo >> >> >>> Cheers, >>> Antho >>> >>> Il giorno mer 3 giu 2020 alle ore 19:53 Vincenzo Maffione < >>> vmaffione@freebsd.org> ha scritto: >>> >>>> Hi Anthony, >>>> I fixed more bugs in the vtnet driver (in FreeBSD-CURRENT). As of >>>> r361760, I'm now able to run the following steps in a VM with a vtnet device >>>> >>>> # ifconfig vtnet0 -txcsum -rxcsum -tso4 192.168.100.2/24 >>>> # vale-ctl -h vale:vtnet0 >>>> # netperf -H 192.168.100.1 # Run a netperf TCP_STREAM test to the host >>>> bridge interface (br0) >>>> >>>> Since TCP works correctly at reasonable speed I'm confident that most >>>> of the existing problems have gone. >>>> Let me know if you have any questions about this. >>>> >>>> Cheers, >>>> Vincenzo >>>> >>>> Il giorno lun 1 giu 2020 alle ore 18:22 Vincenzo Maffione < >>>> vmaffione@freebsd.org> ha scritto: >>>> >>>>> Hi Anthony, >>>>> I think there is more than a bug, drivers-related, that show up when >>>>> you attach the interface to a vale switch. >>>>> I've found and fixed some related to if_vtnet (see below). In any >>>>> case, in my tests there is no difference between TCP traffic and other >>>>> (UDP, ICMP, STP,...). >>>>> The issues are not related to LRO, as I thought. >>>>> There are still more bugs in vtnet and I'm trying to chase them. >>>>> In the meanwhile it would help if you apply the patches below and try >>>>> again with vtnet to see if the situation improves. They apply cleanly to >>>>> 12.1 release. >>>>> >>>>> Regarding your problem with em devices, it is probably yet a different >>>>> issue. It may be related to the iflib transition or not. It would help to >>>>> try the same setup on stable/11 (which does not have iflib). I don't have >>>>> an em device, but I will try with an emulated em in QEMU/KVM. >>>>> >>>>> Cheers, >>>>> Vincenzo >>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> r361698 | vmaffione | 2020-06-01 16:14:29 +0000 (Mon, 01 Jun 2020) | 8 >>>>> lines >>>>> >>>>> netmap: if_vtnet: avoid netmap ring wraparound >>>>> >>>>> netmap assumes the one "slot" is left unused to distinguish >>>>> the empty ring and full ring conditions. This assumption was >>>>> violated by vtnet_netmap_rxq_populate(). >>>>> >>>>> MFC after: 1 week >>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> r361697 | vmaffione | 2020-06-01 16:12:09 +0000 (Mon, 01 Jun 2020) | 8 >>>>> lines >>>>> >>>>> netmap: if_vtnet: replace vtnet_free_used() >>>>> >>>>> The functionality contained in this function is duplicated, >>>>> as it is already available in vtnet_txq_free_mbufs() >>>>> and vtnet_rxq_free_mbufs(). >>>>> >>>>> MFC after: 1 week >>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> r361696 | vmaffione | 2020-06-01 16:10:44 +0000 (Mon, 01 Jun 2020) | >>>>> 13 lines >>>>> >>>>> netmap: vtnet: fix RX virtqueue initialization bug >>>>> >>>>> The vtnet_netmap_rxq_populate() function erroneously assumed >>>>> that kring->nr_hwcur = 0, i.e. the kring was in the initial >>>>> state. However, this is not always the case: for example, >>>>> when a vtnet reinit is triggered by some changes in the >>>>> interface flags or capenable. >>>>> This patch changes the behaviour of vtnet_netmap_kring_refill() >>>>> so that it always starts publishing the netmap buffers starting >>>>> from the current value of kring->nr_hwcur. >>>>> >>>>> MFC after: 1 week >>>>> >>>>> ------------------------------------------------------------------------ >>>>> Il giorno lun 1 giu 2020 alle ore 15:19 Anthony Arnaud < >>>>> antho.arnaudisce@gmail.com> ha scritto: >>>>> >>>>>> Hi Vincenzo, >>>>>> >>>>>> To simplify the scenario I have installed from scratch FBSD12.1 on a >>>>>> new machine, without any virtualization env. >>>>>> I have encountered the same problem, when i attach an ethernet >>>>>> interface to vale switch (in this case an intel card em5) the tcp traffic >>>>>> disappears and tcpdump shown only udp, icmp6 and stp packets. >>>>>> If I detach the NIC from vale0 tcpdump shown all tcp traffic. >>>>>> I'm using the netmap version included in FBSD 12.1, and I have >>>>>> compiled vale-ctl presents in kernel sources (/src/tools/tools/netmap/) >>>>>> I executed your steps. >>>>>> There is something dark about that behaviour... >>>>>> >>>>>> Cheers >>>>>> Anthon >>>>>> >>>>>>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2B_eA9jiJnghcO8Vej3FdZ1y5oO0%2Bmvy=EJEAioB6PMywRyOyA>