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=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 9778AC2BB85 for ; Thu, 9 Apr 2020 19:18:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 61E02208E4 for ; Thu, 9 Apr 2020 19:18:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586459893; bh=yP2d2e1n+GwPcjoxvQGwUTVuQq6EPdlhx4w3UrWLvNg=; h=Date:From:To:Cc:Subject:In-Reply-To:References:List-ID:From; b=s1IfzJU/H23apOlm5UKd+vvl7BtbfpcP2cE5U10vGbm/icULsaBzMJie8f79uAw6Q EDcfhDMH9rFAesGBAys0EdDUcnaLgkv8TGcjwvMWbkKi80t5kJPeuJ9EfNFyHdQKYZ N1BM5gk8oBWXUuTNFgAzPsQQ4lWZ0FUBcK/h26xY= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726821AbgDITSM (ORCPT ); Thu, 9 Apr 2020 15:18:12 -0400 Received: from mail.kernel.org ([198.145.29.99]:55882 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726632AbgDITSL (ORCPT ); Thu, 9 Apr 2020 15:18:11 -0400 Received: from kicinski-fedora-PC1C0HJN (unknown [163.114.132.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id D9D7F206F5; Thu, 9 Apr 2020 19:18:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586459892; bh=yP2d2e1n+GwPcjoxvQGwUTVuQq6EPdlhx4w3UrWLvNg=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Bnm9mrsT4PoTgnq+h7BSHcYMLSw2oBVBrq0w5BOw79A/ZZujiQDh+UiNeSFTbSv85 r9y/ruockZXnOH2LQlN9ziufDA8e+d4t5kNo4TCcXgzX0P5dHyf18StwAaNoV3elfU 1rpWVIXg6s5KXURrdApkIn4K60ltdxar7ZZoWtew= Date: Thu, 9 Apr 2020 12:18:10 -0700 From: Jakub Kicinski To: Daniel Borkmann Cc: Christian Deacon , bpf@vger.kernel.org, aelior@marvell.com, skalluru@marvell.com, netdev@vger.kernel.org Subject: Re: TC BPF Program Crashing With Bnx2x Drivers Message-ID: <20200409121810.26ad70aa@kicinski-fedora-PC1C0HJN> In-Reply-To: <54d3af61-8f00-6f65-23a4-0f1d5a9aba8e@iogearbox.net> References: <853f67f9-6713-a354-07f7-513d654ede91@gflclan.com> <0a96d4ee-e875-e89c-e6bb-e6b62061abdd@gflclan.com> <54d3af61-8f00-6f65-23a4-0f1d5a9aba8e@iogearbox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Thu, 9 Apr 2020 01:57:42 +0200 Daniel Borkmann wrote: > On 4/9/20 1:30 AM, Christian Deacon wrote: > > Hey Daniel, > > > > > > Thank you for your response and I'm glad I'm in the correct area! > > > > > > When the individual ran: > > > > > > ``` > > > > ethtool -K eth0 tso off > > > > ``` > > > > > > The program started operating without crashing. It has been around 20 minutes so far and no crash. Therefore, I'd assume that stopped the crashing considering it usually crashed 20 - 30 seconds after starting the program each time beforehand. I'm not entirely sure what TSO does with this network driver, but I'll try doing some research. > > Yep, don't think it should crash anymore after you turned it off and > it survived since then. ;) I presume GSO is still on in your case, > right (check via `ethtool -k eth0`)? > > > I was suspecting it may be the 'bpf_skb_adjust_room()' function as > > well since I'm using a mode that was implemented in later kernels. > > This function removes the outer IP header in my program from the > > outgoing IPIP packet. I'm not sure what would be causing the > > crashing, though. > > Probably bnx2x folks might be able to help but as mentioned looks > like the tso handling in there has an issue with the ipip which leads > to the nic hang eventually. IMHO this is not a bnx2x problem. The drivers should not have to re-validate GSO flags.. Let's see if I get this right. We have an IPinIP encap, IPXIP4 GSO skb comes down and TC bpf pulls the outer header off, but the gso flags remain unchanged. The driver then sees IPXIP4 GSO but there are no headers so it implodes. Is this correct? And we have the ability to add the right gso flags for encap, not decap (bpf_skb_net_grow() vs bpf_skb_net_shrink()).