From owner-freebsd-net@freebsd.org Tue Nov 21 03:43:08 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 3E250DDCBB3 for ; Tue, 21 Nov 2017 03:43:08 +0000 (UTC) (envelope-from sunxiaoye07@gmail.com) Received: from mail-ot0-x234.google.com (mail-ot0-x234.google.com [IPv6:2607:f8b0:4003:c0f::234]) (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 F13437C2B3 for ; Tue, 21 Nov 2017 03:43:07 +0000 (UTC) (envelope-from sunxiaoye07@gmail.com) Received: by mail-ot0-x234.google.com with SMTP id j29so9416702oth.13 for ; Mon, 20 Nov 2017 19:43:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=OYNUtopu+psxOIbWViqfrCHojFF+0VVW0I9KDOwlHSs=; b=Lzx75WOXbRPJ/WcuIYXZ5JZ+1uECDpdtqXzRzEO1Y0DJchBjjsFGMut7nKOOTsu3dV 6Dh8ex8pVLXq4uDYljG1ZBqjDptixT7nL167kvuHDG6qg+KvHGs2l46A59S7EFQDHKBA FQtXmGM/RzKKCOnAb+Ip3XkyikDKYu0KcSmrLXE1XUZ2xiYrvduS4StCH7sMpEmfQsRE 6Kc0Uo7jDuKyCaFvU8oDvTnLYHKvLyIaPeqdmccVaPFgDE7ZZmn+VN9cDa9ocvsQnAvL pa48sfvQj9j+dyq729TIAOAx/qN2tzxxg1vFWhZC2uipC+qZB1g+ESLieBz4u1ZFNvHf XG1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=OYNUtopu+psxOIbWViqfrCHojFF+0VVW0I9KDOwlHSs=; b=dSb0AS0hqOptUuQ2J6Cv4JPS4C8wGql2lg8XzX8TM+Qmc02tQqpynUenG73dxKwm/u Zym8cUKqDz/b/XjaixhnfbgV2HbUQOOxHySaUki0D8TK2ZGnve7tlH4KROLAvV1PausI tddGlqqQ3uveo1L2hBGFhVFePV0TROEUgaxMhumxsV/VR38rp6uvdku7XgFkWsEV77Py y2R8XhYmUaRgbyzfaVbLUy1VDY4/IjeSA3BIk5/KQ9W4RznCLsnAiDrXJfGTeODqI+YL MOr1ZiLkpEzKGYC+wI3kibbcKnklLyD655G00urei/sF3MPa4IiIl4YaJvJXvsSDh6U4 6okw== X-Gm-Message-State: AJaThX4RUZb0LFu/uarIK1E7Ilp8L4QsACNC82IWPTujcJ78uDNuvs6x iB6BDqglRSjUumJtsOjEyCAeZ2MHDDXfiQj9ufw= X-Google-Smtp-Source: AGs4zMZiCvauiwpik5UlzZmAd/iUqOKrqzcJ1y+k32UOgzD6+o+ZD6IjSN1uc5OgUHOJmPHhScyr34jrlECMiMqYrjI= X-Received: by 10.157.27.101 with SMTP id l92mr9421679otl.315.1511235787161; Mon, 20 Nov 2017 19:43:07 -0800 (PST) MIME-Version: 1.0 Sender: sunxiaoye07@gmail.com Received: by 10.157.14.167 with HTTP; Mon, 20 Nov 2017 19:43:06 -0800 (PST) In-Reply-To: References: From: Xiaoye Sun Date: Mon, 20 Nov 2017 21:43:06 -0600 X-Google-Sender-Auth: q9QZ2dsPVPz9gfNTPs0Ctb6LHw4 Message-ID: Subject: Re: [netmap] when does a packet in the netmap ring send out exactly To: Luigi Rizzo Cc: Vincenzo Maffione , FreeBSD Net 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 03:43:08 -0000 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) > -----------------------------------------+------------------------------- >