> On 23 Jan 2015, at 06:52, Stuart Henderson <[email protected]> wrote:
> 
> On 2015/01/22 10:09, David Gwynne wrote:
>> 
>>> On 21 Jan 2015, at 23:49, Brad Smith <[email protected]> wrote:
>>> 
>>> On 01/21/15 06:51, Jim Smith wrote:
>>>> hi all,
>>>> 
>>>> the below diff enables support for jumbo frames on
>>>> some newer re(4) devices. i've tested it on 8186D/8111D
>>>> and 8186E/8111E chips, which are both able to do 9k
>>>> jumbos. it seems to provide a significant speed-up on
>>>> simple file transfer tests. most of the important parts
>>>> were taken from the freebsd re(4) driver.
>>>> 
>>>> feedback welcome, hope this helps someone.
>>> 
>>> I had started looking into adding support for jumbos to re(4)
>>> but what I have so far does not work; no crashing but the
>>> interface does not receive any packets. What you posted still
>>> needs some work. I'll see if I can get back to it soon-ish but
>>> I have put it aside as it was not intended to be a priority for
>>> the next release.
>> 
>> thats not very constructive feedback, especially if you dont have to time to 
>> tweak the code.
>> 
>> if you could explain what needs work, maybe jim could have a go at it. he's 
>> already spent the time to get it this far, and he said feedback is welcome.
>> 
>> dlg
>> 
>> 
> 
> some minor things I spotted:
> 
> slight KNF issues, some of the new lines are > 80 columns.
> 
> +     case RL_HWREV_8168E:
> +             CSR_WRITE_1(sc, RL_CFG4, CSR_READ_1(sc, RL_CFG4) | 0x01);
> +             break;
> +     default:
> +             CSR_WRITE_1(sc, RL_CFG4, CSR_READ_1(sc, RL_CFG4) | 
> RL_CFG4_JUMBO_EN1);
> +             break;
> 
> there's a new #define for one of these but not the other; probably
> would be preferable to a "magic" 0x01
> 
> +     if ((sc->rl_flags & RL_FLAG_JUMBOV2) != 0) {
> +             ifp->if_capabilities &= ~(IFCAP_CSUM_IPv4);
> +             re_set_jumbo(sc);
> +     }
> 
> wondering...would it be possible to only disable checksum offload iff
> the user has configured a large mtu?

of course. "it's only code". id rather not hang a behaviour change like that 
off the mtu though.

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?

Reply via email to