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 <xiaoye....@rice.edu>: > 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 > <https://github.com/luigirizzo/netmap/tree/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 <ri...@iet.unipi.it> 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 <xiaoye....@rice.edu> 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.maffi...@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 <xiaoye....@rice.edu>: >> >> >> >>> 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-unsubscr...@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-unsubscr...@freebsd.org" >> >> >> >> -- >> -----------------------------------------+------------------------------- >> Prof. Luigi RIZZO, ri...@iet.unipi.it . Dip. di Ing. dell'Informazione >> http://www.iet.unipi.it/~luigi/ . Universita` di Pisa >> TEL +39-050-2217533 . via Diotisalvi 2 >> <https://maps.google.com/?q=via+Diotisalvi+2&entry=gmail&source=g> >> Mobile +39-338-6809875 . 56122 PISA (Italy) >> -----------------------------------------+------------------------------- >> > > -- Vincenzo Maffione _______________________________________________ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
