Steven Stallion wrote:
>> I've put up a webrev at http://cr.opensolaris.org/~gdamore/eri
>>
>> This fixes (I believe) the heap corruption found in eri due to an
>> incorrect handling of the way pullup'd mblks were handled (which,
>> coincidentally, didn't make use of pullupmsg or msgpullup!). I think
>> that problem was most likely introduced when I converted eri to GLDv3.
>>
>> At the same time, to reduce potential opportunity for confusion and
>> errors, I've removed the legacy handling for DMA and DVMA based
>> transmit. The code was very complicated, and my own experiments show
>> very little impact. (In fact, my simpler code appears to run slightly
>> faster on average using ttcp, but the differences observed were too
>> small to be conclusive.) For the record, for ordinary (<= 1500 bytes)
>> ethernet frames, I believe that on the transmit side, it is always
>> faster to simply bcopy. The situation is a bit more complicated for
>> receive, but I've not touched the receive path. (Although this driver
>> also suffers from a very suboptimal receive path. It implements loan up
>> "poorly", getting most of the complexity and almost none of the
>> performance benefit.)
>>
>> I will freely confess that I haven't spent huge amounts of time on all
>> possible permutations for performance analysis of this driver. I
>> believe at this point, we are well past the situation where performance
>> on this driver is critical, as we are only talking about a 100 Mbps
>> driver. I think the improved readability and sustainability, along with
>> no clear loss (or gain!) of performance, is enough to warrant moving
>> ahead at this point without burning many tens of hours in the various
>> test permutations necessary for a truly complete analysis. If anyone
>> feels rather differently, please speak up!
>>
>> In a future RFE, I may remove the loan up of the RX path as well. The
>> RX path has dvma disabled by default, and uses the slower DMA
>> interfaces. Furthermore, it does not use esballoc(), and so I expect
>> the trade off to favor simplification and using simple bcopy to process
>> received packets.
>>
>> Thanks.
>>
>
> Changes look straight-forward (and clean!) to me. I find it very
> interesting that eri did not make use of ddi_device_acc_attr_t.
>
Yeah, that was surprising to me as well. Thanks for reviewing it.
> Questions:
>
> 3489: does this condition warrant a cmn_err? May be tough to track down if
> this ever happens regularly.
>
I don't think so. I am bumping the error counter for now, but I really
don't expect this to ever happen.
> Do you need a hand with testing? (I have an extra eri or two laying around
> collecting dust).
>
I might take you up on it.
-- Garrett
> 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
