From owner-freebsd-net@freebsd.org Fri Oct 27 16:52:48 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 4AEAFE4C059 for ; Fri, 27 Oct 2017 16:52:48 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (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 118DA6FE48 for ; Fri, 27 Oct 2017 16:52:48 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: by mail-io0-x22a.google.com with SMTP id n137so14045299iod.6 for ; Fri, 27 Oct 2017 09:52:48 -0700 (PDT) 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=L7oabb9zIJLF1H/zICGdiNCkFkgdBa6P4e2XhnPzhjE=; b=LoCH9NBG0rQwNxnp+KJXBKgv3f+h8TfvxyrtY4cjz07S+ThBhA55+aspg7Ym3DaTmc n7p4n9a/9lS7N8R2/bVZ77ebRh/C0FJaXbVUfF1vpHAT623mQz190sWGKiw7ECTWWOIT M26Z06/6OR9lTnxTc1kackUzo05y7GIwOt+FeIEWwigdAidodv77wIZWwqVdi3ewHZXe FAwwQhWRhRSUzNGQd2fqRd0yjqhhKPSJx2agOj1o6DIgJPqSV3q38/hOuEDTGNpZ98L8 cyepN0zRV4OObYxABj/6BfMvmbH8r/4gjxbJ1sgyqy3vk7T9lZcZ97+OCYmZbjTVl8lQ Y5nQ== 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=L7oabb9zIJLF1H/zICGdiNCkFkgdBa6P4e2XhnPzhjE=; b=P+Me0p6lyVkSAwpd+J0SOswULJMJW13bvyh3v1iqaWrm0UN0mj8HpBh5tDFhNlM4uL VO3hgpxGGItGO5BROmQ5SZmxhnCKTLE1oTcfMOWwxSTczebIGtrHljiZl23RdYVVmDm4 jAy8fPsHwFHKieyPBFjASjnefJVgQNg1qKRt8TvXYEvR5z6EOm8rGA/SBnCGfXqW6Sci m8gTEnKr15n3Vd0Sb+LarRKYSk4rv+W80cJKgJd7ArlRt8cE9DXbZnt0UVs6kmzX6Zf2 aNn7R8O2NprcZu9DUEOgUz67eitoUsNnvE+rRxOfTyMWMJCfw1371tt9Z73Flqxv5tNI DlEg== X-Gm-Message-State: AMCzsaWtFnmWx1NYlvlAZ1p9wGSz533/JP0U0oB6xXiaXN3+OkArOXjh zjlTReYwbno1Pitn7wX4QwCnXPIOSqbYb1ATvgs= X-Google-Smtp-Source: ABhQp+QjjIflu8oF0DrvwN/EAUcJL7ZEsRW2r4P0IXjO8ampGPRlP1DuCau6Ldjh7/5/jtE4Sk+Eefon5ViELuPGDRI= X-Received: by 10.107.141.206 with SMTP id p197mr1445434iod.92.1509123167119; Fri, 27 Oct 2017 09:52:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.2.176.143 with HTTP; Fri, 27 Oct 2017 09:52:46 -0700 (PDT) In-Reply-To: References: From: Vincenzo Maffione Date: Fri, 27 Oct 2017 18:52:46 +0200 Message-ID: Subject: Re: [netmap] when does a packet in the netmap ring send out exactly To: Xiaoye Sun Cc: FreeBSD Net Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 27 Oct 2017 16:52:48 -0000 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