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=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 90FEFC10F06 for ; Sat, 6 Apr 2019 16:19:48 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 603DC2175B for ; Sat, 6 Apr 2019 16:19:48 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="p6qNMYWY" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 603DC2175B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Mjayd9JAaH7Ab64SXX8HJAw/s0Xs+bodozmRU6gBjL4=; b=p6qNMYWYZQaamG vk6Gfj7y8J+7xhIRjVuYoS7TUt3lZI9Qcrb423pjoLiNxTl5ZUX0ZAR60CZnxizk36mTQD1dnqJ20 TwpWn5eAxRDOXQ40RZ6I0PgzFEW2O541R5fvnsxTaCuxnXXyJBM+sL5CAYxRz9oA/aq9ALXth+Q/b EWNZWvtPVEYy4W/tSKt9aGP3HgRG9a/BUPivhlBckjBDwIrirEVvFI36dRhiymuTYlodGcFE/I8cm 9Hs4XmpnX61MHnXPYNgZPCvxNt2aYXuidGtiE3elSlcso/C/s/mqfdHos8ujm9BPsYdgE4gV+NtTd TVN7phRj3Fw8I/OQZ7nQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hCo2f-0007rC-Kl; Sat, 06 Apr 2019 16:19:41 +0000 Received: from mx1.redhat.com ([209.132.183.28]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hCo2b-0007qf-Ox for linux-arm-kernel@lists.infradead.org; Sat, 06 Apr 2019 16:19:39 +0000 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 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 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) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190406_091937_851321_255BDD17 X-CRM114-Status: GOOD ( 25.80 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Robert Richter , netdev , Ilias Apalodimas , brouer@redhat.com, Sunil Goutham , David Miller , Linux ARM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel