On Thu, Jun 25, 2015 at 10:15 PM, Eric Dumazet <eric.duma...@gmail.com> wrote:
> On Thu, 2015-06-25 at 19:57 -0700, Tom Herbert wrote:
>
>> That may be, but this change would affect all uses of GRO with UDP
>> encapsulation not just for intel 10G NICs. For instance, pushing a lot
>> of checksum calculation into the napi for a single queue device could
>> overwhelm the corresponding CPU-- this is the motivation for the
>> restriction in the first place. We need to do a little more diligence
>> here.
>
> We made the choice of computing checksums years ago when GRO was enabled
> for GRE packets, as many NIC are not able to validate TCP checksums with
> this configuration.
>
But we only started computed checksums for GRE in the device napi with
Jerry's patch:
commit bf5a755f5e9186406bbf50f4087100af5bd68e40
Author: Jerry Chu <hk...@google.com>
Date: Tue Jan 7 10:23:19 2014 -0800
net-gre-gro: Add GRE support to the GRO stack
Or's patch to support GRO for UDP encapsulation which included a check
for checksum complete was accepted a mere 13 days later :-)
We have the option of performing GRO at the tunnel interface and that
is good if we need to do checksum calculation since it is post packet
steering and could heat up cache for an application. If we remove the
checksum check in the udp_gro_receive then the only way to push the
GRO to be done in the tunnel interface would be to disable GRO for
everyone on the Ethernet device. I suspect Ramu's results are without
GRO enabled on the tunnel interface and getting no GRO at all can be
very expensive of course.
Anyway, I am looking at solutions and trying to repro the results.
Tom
> Sure, in some cases this can increase load on softirq handlers, but
> there are some ways to spread load on multi queue NIC.
>
>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
