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=-9.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED 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 576DCC10F06 for ; Sat, 6 Apr 2019 16:19:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 286AA2175B for ; Sat, 6 Apr 2019 16:19:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726468AbfDFQTg (ORCPT ); Sat, 6 Apr 2019 12:19:36 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40210 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726404AbfDFQTg (ORCPT ); Sat, 6 Apr 2019 12:19:36 -0400 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 6517D30BAC44; Sat, 6 Apr 2019 16:19:36 +0000 (UTC) Received: from carbon (ovpn-200-46.brq.redhat.com [10.40.200.46]) by smtp.corp.redhat.com (Postfix) with ESMTP id 45793600CC; Sat, 6 Apr 2019 16:19:30 +0000 (UTC) Date: Sat, 6 Apr 2019 18:19:29 +0200 From: Jesper Dangaard Brouer To: Matteo Croce Cc: David Miller , netdev , Sunil Goutham , Robert Richter , Linux ARM , Ilias Apalodimas , brouer@redhat.com Subject: Re: [PATCH net] net: thunderx: don't allow jumbo frames with XDP Message-ID: <20190406181929.409e693a@carbon> In-Reply-To: References: <20190402231136.15156-1-mcroce@redhat.com> <20190404.172039.1083206882112207747.davem@davemloft.net> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.43]); Sat, 06 Apr 2019 16:19:36 +0000 (UTC) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Fri, 5 Apr 2019 17:45:34 +0200 Matteo Croce wrote: > On Fri, Apr 5, 2019 at 2:51 AM Matteo Croce wrote: > > > > On Fri, Apr 5, 2019 at 2:20 AM David Miller wrote: > > > > > > From: Matteo Croce > > > Date: Wed, 3 Apr 2019 01:11:36 +0200 > > > > > > > The thunderx driver forbids to load an eBPF program if the MTU is > > > > higher than 1500 bytes, but this can be circumvented by first > > > > loading the eBPF, and then raising the MTU. > > > > > > > > XDP assumes that SKBs are linear and fit in a single page, this can > > > > lead to undefined behaviours. > > > > Fix this by limiting the MTU to 1500 bytes if an eBPF program is > > > > loaded. > > > > > > > > Fixes: 05c773f52b96e ("net: thunderx: Add basic XDP support") > > > > Signed-off-by: Matteo Croce > > > > > > Please respond to Jesper's feedback about your choice of a limit of > > > 1500. > > > > > > Otherwise I will toss your patch. > > > > Hi David ad Jesper, > > > > I didn't deliberately choose a limit of 1500, the limit is always set > > in nicvf_xdp_setup(): > > > > /* For now just support only the usual MTU sized frames */ > > if (prog && (dev->mtu > 1500)) { > > netdev_warn(dev, "Jumbo frames not yet supported with XDP... > > > > I just enforced the same limit in another code path which didn't do > > the check. > > If you think that 1500 is a bad value, and I'm sure you're right because > > there isn't room even for VLAN tagging, I will send a series like: > > - 1/2 sets the limit to a resonable value > > - 2/2 enforce the same limit in the two code paths > > > > Regards, > > -- > > Matteo Croce > > per aspera ad upstream > > Hi all, > > I did some tests and I've found that on this driver, the maximum > allowed frame size with XDP is 1530. > Frames bigger than 1530 are split around multiple pages, so the driver > doesn't even run the bpf on them: > > /* For XDP, ignore pkts spanning multiple pages */ > if (nic->xdp_prog && (cqe_rx->rb_cnt == 1)) { > > based on this test, I'll send a series with a proper MTU limit which > should be, correct me if I'm wrong: 1530 - 14 (eth) - 4 (QinQ) = 1512 > bytes. > I subtract only the 4 bytes for the QinQ as the > NETIF_F_VLAN_CHALLENGED_BIT flag is not set, and the first VLAN tag > should not be counted. You *do* need to include the first VLAN tag in the calculation. I guess I didn't explain this clear enough on IRC. XDP cannot use VLAN-offloading. As we explain here[1] when running XDP, you need to disable VLAN-offloading (see cmd in [1]), because XDP need the VLAN header to be "inline" in the packet. XDP don't (yet) have access to reading info from the descriptor. [1] https://github.com/xdp-project/xdp-tutorial/tree/master/packet01-parsing#a-note-about-vlan-offloads -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer