Am Montag, den 28.04.2014, 09:34 -0400 schrieb Neil Horman: > On Sat, Apr 26, 2014 at 12:42:40AM +0200, Carsten Andrich wrote: > > Am Freitag, den 25.04.2014, 07:02 -0400 schrieb Neil Horman: > > > On Thu, Apr 24, 2014 at 06:14:17PM +0200, Carsten Andrich wrote: > > > [...] > > > > +When a malformed packet is encountered on a transmit ring, the default is > > > > +to reset its > > > > +.I tp_status > > > > +to > > > > +.BR TP_STATUS_WRONG_FORMAT > > > > +and abort the transmission immediately (it and following packets are left > > > > +lingering on the ring). > > > > > > I'm not sure this is 100% clear. Any of these error status flags leave the > > > packet in memory on the ring. WRONG_FORMAT, doesn't do anything special here. > > > > The RX-related flags simply denote additional information, which are not > > essential for RX ring operation, i.e. it won't hurt you if you ignore > > them. > > > > TP_STATUS_WRONG_FORMAT is different. It's only set if the transmission > > process is aborted by the kernel. If this occurs the sendto()-call will > > return EINVAL. In this case you have to walk the ring backwards from the > > current userspace frame pointer, look for a frame with tp_status == > > TP_STATUS_WRONG_FORMAT, fix it and set its tp_status = > > TP_STATUS_SEND_REQUEST. I assume PACKET_LOSS was introduced to obviate > > the need to do this. > > > > This should qualify TP_STATUS_WRONG_FORMAT as special. This behaviour > > probably deserves a little more detail in the man-page, but I'll defer > > that until the general overhaul takes place. > > > > I've hacked up a demonstration and attached it. > > Sorry, I'm a freedom-fighter against the 80-character-oppression :) > > > > I also updated my patch for merge-less application to current > > git-master: > > > I'm fine with the example, its the specific reference to the statement "it and > following packets are left lingering on the ring". Thats not special in > relation to WRONG_FORMAT. Even if a packet transmits successfully and gets its > status set back to AVAILABLE, the data of the packet is still in the ring and > can be recovered by user space. Thats all I'm getting at. > Neil I put the lingering-thingy into the TP_STATUS_WRONG_FORMAT description to emphasize, that packets that have actually been scheduled for transmission are still waiting for user-space to clean up its self-made mess and retrigger the transmission. Of course packets don't just vanish from the ring, I just though that this very case deserves to have this explicitly mentioned. Facts like these may not be entirely self-evident to the occasional PACKET_MMAP user and/or man-page reader. But lets cut this short ;) Do you have any concrete suggestions on how to improve the phrasing? Cheers, Carsten -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
