https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240608
--- Comment #15 from Patrick Kelsey <pkel...@freebsd.org> --- (In reply to Andriy Gapon from comment #11) Regarding ignoring rxd->error in the iflib driver: Just as a piece of background information, one thing that is true is that rxd->error can only be set when rx->eop is set (according to reference driver sources). In the error case, we still need iflib to do all of the related completion queue/free list processing for descriptors from sop to eop, but we also have knowledge that the packet is 'bad'. The current treatment of the error indication case is based on the following. There is no facility in the iflib interface (now, or when this driver was written) to indicate this case to iflib. So the vmx driver submits the packet anyway, under the reasoning that it is already possible to receive damaged packets from the network (that pass the checksum checks and so on). It is perhaps not strictly optimal to not take advantage of the early knowledge that the packet is bad, but this does not introduce a new possible condition for the network stack, and this is a rare event. Considering this again, this approach does rely on the virtual device to not provide damaged fragment length indicators (meaning something greater than the configured buffer size) in the error case, and perhaps we should not trust it to do so, in which case the minimal change to what we currently have would be to check rxd->error, and if set, consider the length of the eop fragment to be zero. iflib probably needs an audit on all of the cases of receiving zero length fragments. I may have some time next week to re-analyze the current iflib descriptor/free list mechanism and how the vmx driver interacts with it in order to determine whether there is a bug in the vmx driver, the iflib implementation has shifted since the vmx driver was written in a way that breaks the vmx driver, or everything looks OK and there is some other root cause here. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. _______________________________________________ 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"
