From owner-freebsd-net@freebsd.org Tue Nov 21 07:49:12 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9E40ADE67D9 for ; Tue, 21 Nov 2017 07:49:12 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5371F638C1 for ; Tue, 21 Nov 2017 07:49:12 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: by mail-qt0-x232.google.com with SMTP id r39so17942013qtr.13 for ; Mon, 20 Nov 2017 23:49:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=g+AolEVrcKe2QRifgRSpKfwxTsA/WghOm1PLe+YEMwU=; b=QHduvJ9NO4ideTnsbUH0IL43sFKVz6PSyDVAADCWkrsbsUfffLYFKsSQJzXkGAAkWn QuzL9Ruh7RyXV+/IcnjY3mFs221zn6KUB5d1YLBQqBeJUcHZKMfgJEIXuqplVuCrgW8o cyXyBibb+zM4BMwLAo9QAc6cznth5bhSZaiB4iGDhGstt3nKqKIY1/iJemA2bCy8kEJG Fwdgg2l7q0VqxoCxiRX3jy/uaNplODdEDvg3CxGbHpbwtVc6wKMx+dLVUTnSH63nlvFO B00J2Uasnl3gJiKYzYp0Re65wwmx3q4PGKy9IGLf0AN5dZMi9oIk3/vL5CGmM7QytliM CsGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=g+AolEVrcKe2QRifgRSpKfwxTsA/WghOm1PLe+YEMwU=; b=gcNd+jpW9k2b9dWP0NWzkgfH/0XpOpRuZiAKdvkucG96b0LTK6SI3NxYrm2NaOrM17 q2JAUKEynYE5ieh4U1DMnNi21SnjDyuuCQkJ7VmBeNfFrZAbCBSBIFtWqT/BqmudUNav FfC2YS/aB2stEdz9K+Fjc1HNjolzqFKCi799NhZtbtxnV8y1Nze8mrLtsJAsnY8f22wI 9zqv0Uzk/8nfl8KobTcKH2Cf3uw8A29LYf2PfcoDCQQ79ldVeqnRaAltG3MxkCqwzzS3 oOlNPbl8ZvDmF3Wf2CrRytG8mfWOwdGm04ip0FIcDyOatLUGj5T07JtpF2I+6eBa2Miy /+vA== X-Gm-Message-State: AJaThX6zaqISk9BQkkijhg0uJudCEEypBJhUCi8XuhVRHZl30ks62maq dvJCLLo8XB00nk7fXT4HVbrwjnys+zAUYcZeBUo= X-Google-Smtp-Source: AGs4zMaej/x59YehkZXLPIU17C2ffMh+fvbi2nCO6ykp2Ax60Ofklp3ktBoipEnV/umYRuVsbzROFevhTUOQnspLxaI= X-Received: by 10.200.35.90 with SMTP id b26mr25319922qtb.324.1511250551177; Mon, 20 Nov 2017 23:49:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.174.25 with HTTP; Mon, 20 Nov 2017 23:49:10 -0800 (PST) In-Reply-To: References: From: Vincenzo Maffione Date: Tue, 21 Nov 2017 08:49:10 +0100 Message-ID: Subject: Re: [netmap] when does a packet in the netmap ring send out exactly To: Xiaoye Sun Cc: Luigi Rizzo , FreeBSD Net , Giuseppe Lettieri Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Nov 2017 07:49:12 -0000 Hi, Netmap version (tag v11.3 vs master) should be unrelated. Are you using ixgbe? In this case it may depend on the ixgbe driver version that netmap is using for patching. On github master you can change the version by modifying the ixgbe line in LINUX/default-config.mak.in_. Valid versions are for instance 4.5.4 or 5.1.3. Cheers, Vincenzo 2017-11-21 4:43 GMT+01:00 Xiaoye Sun : > Hi Luigi, > > Thanks! > I was using the most recent netmap on Github and I believe the tail > pointer only moves forward when there are less than half of the total slots > available in the netmap ring. > Then I switch to the version of v11.3 > , it behaves as what you > described. > > Linux Kernel: 3.16.0-4-amd64 > > Best, > Xiaoye > > > On Mon, Nov 20, 2017 at 6:11 PM, Luigi Rizzo wrote: > >> Hi, >> I think if you call the TXSYNC ioctl without advancing the head >> pointer, then the tail is advanced >> as much as possible. >> >> Cheers >> luigi >> >> On Mon, Nov 20, 2017 at 3:35 PM, Xiaoye Sun wrote: >> > Hi, >> > >> > I found that the tail pointer only moves when the ring has less than >> half >> > of the slots available. This prevents me from knowing the accurate time >> > when the packet in a slot is processed. Is there a way to move the tail >> > pointer as long as the packet in the slot is processed? Is this a >> > configurable feature? >> > >> > Best, >> > Xiaoye >> > >> > On Fri, Oct 27, 2017 at 11:52 AM, Vincenzo Maffione < >> v.maffione@gmail.com> >> > wrote: >> > >> >> Hi, >> >> This is actually a limitation of the netmap API: ring->tail is >> exposed >> >> to the user so that it knows it can use the slots in the range >> >> "[ring->head..ring->tail[" for new transmissions (note that head is >> >> included, tail excluded, to prevent wraparound). However, there is no >> >> explicit indication of "up to what slots packets were transmitted". >> >> For hw NICs, however, ring->tail is an indication of where transmission >> >> was completed. >> >> Example: >> >> 1) at the beginning ring->tail = ring->head = ring->cur = 0 >> >> 2) then your program moves head/cur forward: head = cur = 10 >> >> 3) you call TXSYNC, to submit the packets to the NIC. >> >> 4) after the TXSYNC call, is very likely that tail is still 0, i.e. >> >> because no transmission has been completed by the NIC (and no interrupt >> >> generated). >> >> 5) say after 20 us you issue another TXSYNC, and in the meanwhile 6 >> >> packets had completed. In this case after TXSYNC you will find tail==5, >> >> meaning that packets in the slots 0,1,2,3,4 and 5 have been completed. >> Note >> >> that also the slot pointed by tail has been completed. >> >> >> >> But you are right that there is no way to receive completion >> notification >> >> if the queue is not full. You must use TXSYNC to check (by sleeping or >> busy >> >> wait) when tail moves forward. >> >> >> >> Cheers, >> >> Vincenzo >> >> >> >> >> >> 2017-10-27 3:06 GMT+02:00 Xiaoye Sun : >> >> >> >>> Hi >> >>> >> >>> I write a netmap program that sends packets to the network. my program >> >>> uses one netmap ring and fills the ring slots with packets. >> >>> My program needs to do something (action A) after a particular packet >> >>> (packet P) in the ring slot is sent to the network. so the program >> tracks >> >>> the position of the tail point and checks if the tail point has moved >> >>> across the slot I used to put that packet P. >> >>> However, I found that the tail pointer may not move forward even >> seconds >> >>> after the receiver side got packet P. >> >>> Sometimes the tail pointer never moves forward until the TX ring is >> full. >> >>> I try ioctl(NIOCTXSYNC), however, it cannot 100% solve the problem. >> >>> >> >>> My question is that is there a way to make the TX ring empty as early >> as >> >>> possible so that I can know when my packet is sent out. or is there >> >>> another >> >>> way to know when the packet in the slot is sent to the network/NIC >> >>> physical >> >>> queue? >> >>> >> >>> I am using Linux 3.16.0-4-amd64. >> >>> >> >>> Thanks! >> >>> >> >>> Best, >> >>> Xiaoye >> >>> _______________________________________________ >> >>> freebsd-net@freebsd.org mailing list >> >>> https://lists.freebsd.org/mailman/listinfo/freebsd-net >> >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org >> " >> >>> >> >> >> >> >> >> >> >> -- >> >> Vincenzo Maffione >> >> >> > _______________________________________________ >> > freebsd-net@freebsd.org mailing list >> > https://lists.freebsd.org/mailman/listinfo/freebsd-net >> > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> >> >> >> -- >> -----------------------------------------+------------------------------- >> Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione >> http://www.iet.unipi.it/~luigi/ . Universita` di Pisa >> TEL +39-050-2217533 . via Diotisalvi 2 >> >> Mobile +39-338-6809875 . 56122 PISA (Italy) >> -----------------------------------------+------------------------------- >> > > -- Vincenzo Maffione