[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKgT0UcP4noG_=puoi=zsfMi33RUSTMTL6RGLCPSR=nsVtXiag@mail.gmail.com>
Date: Tue, 5 Jan 2021 09:30:23 -0800
From: Alexander Duyck <alexander.duyck@...il.com>
To: Rohit Maheshwari <rohitm@...lsio.com>
Cc: Jakub Kicinski <kuba@...nel.org>, Netdev <netdev@...r.kernel.org>,
David Miller <davem@...emloft.net>, secdev@...lsio.com
Subject: Re: [net] cxgb4: advertise NETIF_F_HW_CSUM
On Tue, Jan 5, 2021 at 9:01 AM Rohit Maheshwari <rohitm@...lsio.com> wrote:
>
> advertise NETIF_F_HW_CSUM instead of protocol specific values of
> NETIF_F_IP_CSUM and NETIF_F_IPV6_CSUM. This change is added long
> back in other drivers. This issue is seen recently when TLS offload
> made it mandatory to enable NETIF_F_HW_CSUM.
>
> Fixes: 2ed28baa7076 ("net: cxgb4{,vf}: convert to hw_features")
> Signed-off-by: Rohit Maheshwari <rohitm@...lsio.com>
> ---
> drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
> index 7fd264a6d085..f99f43570d41 100644
> --- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
> +++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
> @@ -6831,14 +6831,13 @@ static int init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
> netdev->irq = pdev->irq;
>
> netdev->hw_features = NETIF_F_SG | TSO_FLAGS |
> - NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM |
> + NETIF_F_HW_CSUM |
> NETIF_F_RXCSUM | NETIF_F_RXHASH | NETIF_F_GRO |
> NETIF_F_HW_VLAN_CTAG_TX | NETIF_F_HW_VLAN_CTAG_RX |
> NETIF_F_HW_TC | NETIF_F_NTUPLE;
>
> if (chip_ver > CHELSIO_T5) {
> - netdev->hw_enc_features |= NETIF_F_IP_CSUM |
> - NETIF_F_IPV6_CSUM |
> + netdev->hw_enc_features |= NETIF_F_HW_CSUM |
> NETIF_F_RXCSUM |
> NETIF_F_GSO_UDP_TUNNEL |
> NETIF_F_GSO_UDP_TUNNEL_CSUM |
If you are going to enable the feature you should fully enable the
feature. My concern is the "nocsum:" label in hwcsum(). If you are
going to say you support the feature you should at least look at
dealing with the exception case and process a software checksum via
skb_checksum_help() rather than just not bothering and "hope a bad
packet is detected".
- Alex
Powered by blists - more mailing lists