On Sun, 2015-09-27 at 22:37 -0700, Tom Herbert wrote:
>
> Which drivers are doing this? It is up to the driver to determine
> whether a particular packet being sent can have checksum offloaded to
> the device. If it cannot offload the checksum it must call
> skb_checksum_help.
Not so.
A driver s
On Thu, Sep 24, 2015 at 5:31 AM, David Woodhouse wrote:
> On Thu, 2015-09-24 at 05:05 -0700, Eric Dumazet wrote:
>>
>> Right, netif_skb_features() only has the following checks :
>>
>> if (gso_segs > dev->gso_max_segs || gso_segs < dev->gso_min_segs)
>> features &= ~NETIF_F_GSO_MASK;
>>
>> But
From: David Woodhouse
Date: Thu, 24 Sep 2015 11:38:22 +0100
> When fixing the TSO support I noticed we just mask ->gso_size with the
> MSSMask value and don't care about the consequences.
>
> Provide a .ndo_features_check() method which drops the NETIF_F_TSO
> feature for any skb which would exc
On Thu, 2015-09-24 at 05:05 -0700, Eric Dumazet wrote:
>
> Right, netif_skb_features() only has the following checks :
>
> if (gso_segs > dev->gso_max_segs || gso_segs < dev->gso_min_segs)
> features &= ~NETIF_F_GSO_MASK;
>
> But now we have .ndo_features_check() we could remove this generic
On Thu, 2015-09-24 at 11:38 +0100, David Woodhouse wrote:
> When fixing the TSO support I noticed we just mask ->gso_size with the
> MSSMask value and don't care about the consequences.
>
> Provide a .ndo_features_check() method which drops the NETIF_F_TSO
> feature for any skb which would exceed
When fixing the TSO support I noticed we just mask ->gso_size with the
MSSMask value and don't care about the consequences.
Provide a .ndo_features_check() method which drops the NETIF_F_TSO
feature for any skb which would exceed the maximum, and thus forces it
to be segmented by software.
Then w
