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 -- 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
