netdev - Re: [PATCH 2/2 net-next] net: drivers: set TSO/UFO offload option explicitly

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 05 May 2011 16:51:59 +0800
From:	Shan Wei <shanwei@...fujitsu.com>
To:	Michał Mirosław <mirqus@...il.com>
CC:	David Miller <davem@...emloft.net>,
	netdev <netdev@...r.kernel.org>, rusty@...tcorp.com.au,
	mst@...hat.com, Eric Dumazet <eric.dumazet@...il.com>,
	mirq-linux@...e.qmqm.pl, bhutchings@...arflare.com, dm@...lsio.com
Subject: Re: [PATCH 2/2 net-next] net: drivers: set TSO/UFO offload option
 explicitly

Michał Mirosław wrote, at 05/04/2011 08:36 PM:
> 2011/4/29 Shan Wei <shanwei@...fujitsu.com>:
>> The device drivers should not use NETIF_F_ALL_TSO mask to set hw_features(or features),
>> but have to explicitly set offload option. Because, This would make drivers automatically
>> clain to support any new TSO feature an the moment of NETIF_F_ALL_TSO is expanded.
>>
>> Some code style tuning. Just compile test.
>>
>> Signed-off-by: Shan Wei <shanwei@...fujitsu.com>
>> ---
>>  drivers/net/loopback.c   |   18 ++++++++----------
>>  drivers/net/virtio_net.c |    9 ++++++---
>>  2 files changed, 14 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/net/loopback.c b/drivers/net/loopback.c
>> index d70fb76..bfb6a4a 100644
>> --- a/drivers/net/loopback.c
>> +++ b/drivers/net/loopback.c
>> @@ -152,6 +152,9 @@ static const struct net_device_ops loopback_ops = {
>>        .ndo_get_stats64 = loopback_get_stats64,
>>  };
>>
>> +#define LOOPBACK_USER_FEATURES (NETIF_F_TSO | NETIF_F_TSO_ECN | \
>> +                               NETIF_F_TSO6 | NETIF_F_UFO)
>> +
>>  /*
>>  * The loopback device is special. There is only one instance
>>  * per network namespace.
>> @@ -165,16 +168,11 @@ static void loopback_setup(struct net_device *dev)
>>        dev->type               = ARPHRD_LOOPBACK;      /* 0x0001*/
>>        dev->flags              = IFF_LOOPBACK;
>>        dev->priv_flags        &= ~IFF_XMIT_DST_RELEASE;
>> -       dev->hw_features        = NETIF_F_ALL_TSO | NETIF_F_UFO;
>> -       dev->features           = NETIF_F_SG | NETIF_F_FRAGLIST
>> -               | NETIF_F_ALL_TSO
>> -               | NETIF_F_UFO
>> -               | NETIF_F_NO_CSUM
>> -               | NETIF_F_RXCSUM
>> -               | NETIF_F_HIGHDMA
>> -               | NETIF_F_LLTX
>> -               | NETIF_F_NETNS_LOCAL
>> -               | NETIF_F_VLAN_CHALLENGED;
>> +       dev->hw_features        = LOOPBACK_USER_FEATURES;
>> +       dev->features           = NETIF_F_SG | NETIF_F_FRAGLIST
>> +               | LOOPBACK_USER_FEATURES | NETIF_F_NO_CSUM | NETIF_F_RXCSUM
>> +               | NETIF_F_HIGHDMA | NETIF_F_LLTX
>> +               | NETIF_F_NETNS_LOCAL | NETIF_F_VLAN_CHALLENGED;
>>        dev->ethtool_ops        = &loopback_ethtool_ops;
>>        dev->header_ops         = &eth_header_ops;
>>        dev->netdev_ops         = &loopback_ops;
> 
> You can add NETIF_F_HIGHDMA and NETIF_F_NO_CSUM to
> LOOPBACK_USER_FEATURES in one go. NETIF_F_RXCSUM could match
> NETIF_F_NO_CSUM state (this needs ndo_fix_features callback), but this
> won't have much real functional impact.

Do you mean that defining LOOPBACK_USER_FEATURES as:
#define LOOPBACK_USER_FEATURES (NETIF_F_TSO | NETIF_F_TSO_ECN | \
                               NETIF_F_TSO6 | NETIF_F_UFO | NETIF_F_HIGHDMA | NETIF_F_NO_CSUM)

Is it necessary to add NETIF_F_NO_CSUM to hw_features?
After that, user can change TX hw csum offload(NETIF_F_NO_CSUM is disabled). But, this is not surportted before.

-- 
Best Regards
-----
Shan Wei
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html