Steven Stallion wrote: > Garrett D'Amore wrote: >> On transmit, the best thing to do is pad with zeros. (This is >> important to prevent a security leak where "short" packets can >> unintentionally contain data from another packet, possibly sent to a >> different host.) > > Good point - I'll update. > > I'm still trying to narrow down the cause for frame corruption on > transmit. Compared with similar drivers on Linux, *BSD, and even Masa's > ni driver I am not doing anything differently. > >> On receive, you should never need to strip. If the packet is less than >> the minimum size, you should probably just drop it on the floor, if the >> hardware doesn't already do that for you. > > Unfortunately the RTL8029 doesn't do much in terms of hardware, however > I do have a check in place which increments the runt_errors kstat and > drops the packet. There is no logic in place to deal with padded packets.
Usually, the MAC controller has the capability to do tx padding and rx stripping when needed as long as the corresponding bit is set during the initialization. And MAC also has the statistics for received runt packets. Does RTL8029AS has such capabilities? Sorry I do not check the datasheet. Thanks, Lucy > >> On another note, mgmt has asked me about your DNET gldv3 work -- can you >> provide a status update on it? > > Certainly. > > The GLDv3 conversion has been complete for quite some time now - I have > not encountered any regressions in nicdrv testing so far. Jason King had > a friend interested in the conversion and has been testing the changes > (64-bit variety) for the last few months with no issues as well. > > To be honest, I had been holding off on submitting until I could make a > couple more passes with nicdrv to present a comprehensive set of test > results, however life, and re have interfered somewhat. > > I will finalize all changes and make a last run of nicdrv testing by > next week to get ready for an RTI. > > Steve > _______________________________________________ > driver-discuss mailing list > driver-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/driver-discuss > _______________________________________________ driver-discuss mailing list driver-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/driver-discuss
