On 2015/02/18 11:57, Jim Smith wrote: > On Fri, Jan 23, 2015 at 11:26:53AM +1000, David Gwynne wrote: > > a compromise could be to advertise checksum offload to the stack, > > pass it on to the hardware for small frames but have the driver do > > it in software for the big ones? > > greetings, > > below are two diffs. the first allows re(4) chips to handle checksums > in software for large packets. this allows the chip to advertise hardware > checksums for regular packets and do it manually for jumbos, which the > the hardware cannot do properly (at least for 8168D and 8168E chips, which > i've tested). > > the second diff is the same as the previous jumbo diff i sent through, > but does not disable hw csums for the 8168D and 8168E chips. > > the first will do nothing without the second, but the diff's goals > are different enough that two make sense. > > thanks dlg@ for the original concept and for hammering square pegs into > my round brain. feedback appreciated.
I'm not finding many re(4) machines to test it on here. I think I have a card somewhere but haven't tracked it down yet. No regressions with this (non jumbo capable) hardware.. re0 at pci2 dev 0 function 0 "Realtek 8101E" rev 0x02: RTL8102EL (0x2480), msi, address 00:23:8b:43:96:e6 rlphy0 at re0 phy 7: RTL8201L 10/100 PHY, rev. 1 ..not that I would expect problems from reviewing the diffs. OK for the first diff. It changes nothing for existing cases, and only has an effect when both 1) second diff is applied and 2) mtu is raised. Second diff I'm pretty much OK with but considering the time we're at in the release cycle and the number of different re devices existing, it would be nice to have more reports.
