Xiu-Yan Wang wrote:
> 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.
Often the NIC padding functionality is buggy, and just reuses bits from
previous packets. I wouldn't rely on it unless you've verified that the
hardware doesn't suffer from this bug. (And older hardware is more
likely to have the problem.)
-- Garrett
>
> 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
>> [email protected]
>> http://mail.opensolaris.org/mailman/listinfo/driver-discuss
>>
>
_______________________________________________
driver-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
