From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3448CC32792 for ; Mon, 30 Sep 2019 23:57:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id F0C8B2075D for ; Mon, 30 Sep 2019 23:57:09 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="ViHQiKAE" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729057AbfI3X5J (ORCPT ); Mon, 30 Sep 2019 19:57:09 -0400 Received: from mail-io1-f67.google.com ([209.85.166.67]:34843 "EHLO mail-io1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727146AbfI3X5J (ORCPT ); Mon, 30 Sep 2019 19:57:09 -0400 Received: by mail-io1-f67.google.com with SMTP id q10so43186816iop.2 for ; Mon, 30 Sep 2019 16:57:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bdGkRO3c9VgU0ezFX7A/dKMILtCJSCMs3+QGCOpCIWw=; b=ViHQiKAEx1n562HpDMBYzNGmWGbUjQu2WyN2BxdJm0CGoFQrzJepbuznYDiQ6Tconj X9chgZOa4jRjgvc5MZXFk2B8Pf7AKViimqUBzXT+szgnLM6ND2VUDCa9lntWOLCB7QvM bgF51BgnNGbAGgr1wGbq94Txv1/itH9gmKo8yDqVMvyqNiVvkIG8hm5Q8Jb+aPX07+kA 1X9OPo7k66k+Fl4q+P2Rcy951p+svQw72lFVpdda48DoFqU2Dq6weNp35j6GVKIC3nq9 3ULLg0tp9zUG0rz9kYHgLyTSMK08zxvGHogt/fxcqqE9B+lCLHwOIyVaICCy3WvjiphW GkJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bdGkRO3c9VgU0ezFX7A/dKMILtCJSCMs3+QGCOpCIWw=; b=dc0LDkiW+UQ4clzUERycpWc9a796eV98pHYT3tUAAUPFTrIhIqJW/xby2UvLx7wgW7 uY8XKVqFEKEqgx3DwOagCUbwPN6PHRBatlXLeGrfAQD0GwmgTxENA8dK3gZkQ7f4oqRr 62F5UKYz6mcvi36vYYEpbLtPbeImacqyjRWDELMFyLYYjA7iWm3pfpnf/QGMuOC2h3zS w5/r0X3GwmdGOrOer7JMyj697NWkbO8FkyyzdyV30Ij4u+iydY2Bp5QG8iXudU88MzAD wzYOq2xuTVHQz9Ln34WblSHABCRJqT5ngLR2oyCDDgyO3TS6yhEXzc4pE6sELXFnxusf GSug== X-Gm-Message-State: APjAAAV1QPCqo88h+zwnkQ8gvQkC3UoBIMV6PZRTBzqHNonxNbMt+g3l Nr1qT0/7/nbNwHy2/kLDaBFEGhopLHd0XIjE59c= X-Google-Smtp-Source: APXvYqw9HonPf8idhyRHOLF3337kPdc2FXY47IEsPbO8e98Qmd1sOeEdgkcijjK8fUMjTR+6YRduAm9Yg6gRc6H+YSU= X-Received: by 2002:a92:b743:: with SMTP id c3mr23457392ilm.237.1569887827927; Mon, 30 Sep 2019 16:57:07 -0700 (PDT) MIME-Version: 1.0 References: <1569881518-21885-1-git-send-email-johunt@akamai.com> <1569881518-21885-2-git-send-email-johunt@akamai.com> In-Reply-To: <1569881518-21885-2-git-send-email-johunt@akamai.com> From: Alexander Duyck Date: Mon, 30 Sep 2019 16:56:56 -0700 Message-ID: Subject: Re: [PATCH 2/2] udp: only do GSO if # of segs > 1 To: Josh Hunt Cc: David Miller , Netdev , Eric Dumazet , Willem de Bruijn , "Duyck, Alexander H" Content-Type: text/plain; charset="UTF-8" Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Mon, Sep 30, 2019 at 3:13 PM Josh Hunt wrote: > > Prior to this change an application sending <= 1MSS worth of data and > enabling UDP GSO would fail if the system had SW GSO enabled, but the > same send would succeed if HW GSO offload is enabled. In addition to this > inconsistency the error in the SW GSO case does not get back to the > application if sending out of a real device so the user is unaware of this > failure. > > With this change we only perform GSO if the # of segments is > 1 even > if the application has enabled segmentation. I've also updated the > relevant udpgso selftests. > > Fixes: bec1f6f69736 ("udp: generate gso with UDP_SEGMENT") > Signed-off-by: Josh Hunt > --- > net/ipv4/udp.c | 5 +++-- > net/ipv6/udp.c | 5 +++-- > tools/testing/selftests/net/udpgso.c | 16 ++++------------ > 3 files changed, 10 insertions(+), 16 deletions(-) > > diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c > index be98d0b8f014..ac0baf947560 100644 > --- a/net/ipv4/udp.c > +++ b/net/ipv4/udp.c > @@ -821,6 +821,7 @@ static int udp_send_skb(struct sk_buff *skb, struct flowi4 *fl4, > int is_udplite = IS_UDPLITE(sk); > int offset = skb_transport_offset(skb); > int len = skb->len - offset; > + int datalen = len - sizeof(*uh); > __wsum csum = 0; > > /* > @@ -832,7 +833,7 @@ static int udp_send_skb(struct sk_buff *skb, struct flowi4 *fl4, > uh->len = htons(len); > uh->check = 0; > > - if (cork->gso_size) { > + if (cork->gso_size && datalen > cork->gso_size) { > const int hlen = skb_network_header_len(skb) + > sizeof(struct udphdr); > So what about the datalen == cork->gso_size case? That would only generate one segment wouldn't it? Shouldn't the test really be "datalen < cork->gso_size"? That should be the only check you need since if gso_size is 0 this statement would always fail anyway. Thanks. - Alex