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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E85E2C433F5 for ; Sat, 5 Mar 2022 16:54:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232167AbiCEQyv (ORCPT ); Sat, 5 Mar 2022 11:54:51 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56766 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232118AbiCEQyl (ORCPT ); Sat, 5 Mar 2022 11:54:41 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3F9A546670 for ; Sat, 5 Mar 2022 08:53:51 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id EB530B80C94 for ; Sat, 5 Mar 2022 16:53:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DADD9C004E1; Sat, 5 Mar 2022 16:53:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1646499228; bh=yHcHKUkpEt4AN6MdE0Clenbr3T34gdX7zCf72EttqJs=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=HmoW1xkgcpMixExSiUo+4TVS7SI8NG+DqNSwSr2dj9v47Bh+OkSQU9EeuviFSFgd3 zssK0T1mHAz1k5MeEsMaNaqufvUsY1XsZ6zMdQGjHPZnbQkKFEractbyDNkMJxx1vL Pfq1gWFfQcDqkdY8hk0hwtlsOACnTyMkNDAcmjRfba80H4m6/kQ6CKcv5AvYSxFrx1 j91yRoxmdguyrUJ+lpaE/HhPGHFn44+1iMwBCl2fhu9yJFXID6V1bXS84y7hm4M7/W 7847EeuBfqnrApdDY40qTe33nFWs85zcFh1rYfMpZx2ieIlIv9uYzqP323RZpiS2Q9 tqQEg+R+pCo3Q== Message-ID: Date: Sat, 5 Mar 2022 09:53:46 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Subject: Re: [PATCH v2 net-next 08/14] ipv6: Add hop-by-hop header to jumbograms in ip6_output Content-Language: en-US To: Eric Dumazet , Alexander H Duyck Cc: Eric Dumazet , "David S . Miller" , Jakub Kicinski , netdev , Coco Li , Alexander Duyck References: <20220303181607.1094358-1-eric.dumazet@gmail.com> <20220303181607.1094358-9-eric.dumazet@gmail.com> <726720e6-cd28-646c-1ba3-576a258ae02e@kernel.org> From: David Ahern In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 3/4/22 12:13 PM, Eric Dumazet wrote: >> I am not saying we have to do this. I am simply stating a "what if" >> just to gauge this approach. You could think of it as thinking out >> loud, but in written form. my point as well. > > Understood. > > BTW I spent time adding a new gso_type flag, but also gave up because we have > no more room in features_t type. > > Solving features_t exhaustion alone is a delicate topic. > > >> >>> For instance, input path will not like packets larger than 64KB. >>> >>> There is this thing trimming padding bytes, you probably do not want >>> to mess with this. >> >> I had overlooked the fact that this is being used on the input path, >> the trimming would be an issue. I suppose the fact that the LSOv2 >> didn't have an Rx counterpart would be one reason for us to not >> consider the IPv4 approach. >> I'm aware of the trim on ingress; it can be properly handled. Drivers (LRO) and the S/W GRO stack would know when it is exceeding the 64kB length so the skb can be marked that is a large packet. I am not trying to derail this set from getting merged. v6 has a standard header for the large packet support, so certainly use it. That said, it is always best in the long run for IPv4 and IPv6 to have consistent feature support and implementation. Hence the asking about alternative solutions that work for both.