From owner-freebsd-net@freebsd.org Fri Jun 5 16:16:36 2020 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C246333057B for ; Fri, 5 Jun 2020 16:16:36 +0000 (UTC) (envelope-from antho.arnaudisce@gmail.com) Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49dnpC6rx0z4D2Z; Fri, 5 Jun 2020 16:16:35 +0000 (UTC) (envelope-from antho.arnaudisce@gmail.com) Received: by mail-ot1-x329.google.com with SMTP id g7so6940501oti.13; Fri, 05 Jun 2020 09:16:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MO2RzUeB9gnsvUcnCuEeIkE4WSzgcyq+56qWu6tqmvM=; b=YEpXVT6ZzPDnAhFPZvyth8NPs5GEjGoZDoWqGqLOUHsg1bR9N0yXWewj3tO7Ocl4Z6 66BOfLIumrw4TLGlurGMbMim6bae4l0iavXLdhxloMG7tZ1C3zDmLObTb+L3VxRHbXRO AAXnhWEkwOaFg1E2B4WhRuNR6CYJPLPDc6Le4LJg+6T1kDjxw93RmgqQTLB+OYxC/92E 8AdEE6uiw9HHpYbmw8iT8v/P7+HhmnRBBbrh1sxITJ91Yb1P/8yb2Sms6BbP8BIJPxNa 5unkCd7nt+3QPRl9jptxgUsywcCuaHmyG5mm5DPyEJsgq+I2JP9BD2SOh1KKauJbFBDG 4EXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MO2RzUeB9gnsvUcnCuEeIkE4WSzgcyq+56qWu6tqmvM=; b=YYPWY/XlHNI1ddkZGD1uFDJO3MH+ISML/RnwN+xdHL+S3f2lMqodLkazvfxZmBm/6P a3GrahFJ5OrJsi29KjMI2eYFgp+hdPbUWdwgL8mU3CclJd+msFb6rboM4yNy5af1ynQp KbwWaA/v2KEa14cwBiul1H11rmuwyCKjhuFojhkTVBW15NaabT06T74m6xIhJz00hGxM OEw9kJvhCi4TodRd/1x5bjXqusJCGPxE+cMQ6JjzxJmOGsE24I29gXbJU6NG59P4RRhL dNpabRfsQ8283enQTfjTK6aGtJOXYplw2Kw10P0JWdv53l17fL8A+9pJNWa9y1nQZaE3 hJ0A== X-Gm-Message-State: AOAM533xwEK6EJJG8hAXx3jXBSfSuYx2DIzm3QMzFtdGpb/Zim0P832a gToWLFF5+trbFQVmzJ74UJJW+GWgARgo6qOD+Nf+nxj1 X-Google-Smtp-Source: ABdhPJzWj9w23foNgIyDcOzQl6sxM/LWjhMBGYOQgWV+WylgU5PH+IDs8SVyIa/dx1/aaWwejih13WJDbvHknGALkBM= X-Received: by 2002:a9d:4703:: with SMTP id a3mr7932610otf.219.1591373794458; Fri, 05 Jun 2020 09:16:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Anthony Arnaud Date: Fri, 5 Jun 2020 18:16:24 +0200 Message-ID: Subject: Re: Netmap - Vale switch - tcp problem To: Vincenzo Maffione Cc: Luigi Rizzo , "freebsd-net@freebsd.org" X-Rspamd-Queue-Id: 49dnpC6rx0z4D2Z X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=YEpXVT6Z; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of anthoarnaudisce@gmail.com designates 2607:f8b0:4864:20::329 as permitted sender) smtp.mailfrom=anthoarnaudisce@gmail.com X-Spamd-Result: default: False [-1.01 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; URI_COUNT_ODD(1.00)[1]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.02)[-0.021]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.004]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-0.98)[-0.982]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::329:from]; HTTP_TO_IP(1.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2020 16:16:36 -0000 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. "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? 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 >>> >>>