Received: by 2002:a05:7412:d8a:b0:e2:908c:2ebd with SMTP id b10csp1149822rdg; Fri, 13 Oct 2023 11:39:49 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGmB9FMbhOENtsJXe5jpd5cjFC+tU64LJLPPvMDyLGh2PoiD6DczRx3zKitQ63DHR5+RnEs X-Received: by 2002:a17:902:ea11:b0:1c8:7d21:fc63 with SMTP id s17-20020a170902ea1100b001c87d21fc63mr26942083plg.56.1697222389284; Fri, 13 Oct 2023 11:39:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697222389; cv=none; d=google.com; s=arc-20160816; b=hOnPOUsfNaoS4+Yc+D9AZGi6f6hLYxRHVjgBc7WWkWmF1gnPyyU6rhVUwFnU8oLZ0z 6d2HWV2s0rIRpihraFFgkL5AkCQIeVWKxh6cYCXhYuVy80V0G1dtZW6ugJ2mOUraCicZ 0L/heVSFVk6f4Dhnj2huD+gWQtbfE5zBX4KMDk75G5WIUmgSXr4C8AljnEcocUsMxRaB Fttp/conEoR2q/4usHvqNUEt8UGGUBw47OF63PavJAsaW/tAmi8mwkH2yqG+JbxZaXwN vQTakM+t6JH0RSZmino+NQvnZ0YTXkX8K6sZ3944c/pdnT3rSdYCscEPnXMZ1bw6QR92 1s5Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=q2ohtkcvpEvo61Q68fjCDCwlB06zwFzfj4hgniJlyos=; fh=sUzFhheJP6ORqa8FeWDqX2SGjTp2rOCbrGgrBhqE6Jk=; b=Pk0j3nYdSj0JjSmB5P0N57qr8+dA93INH7ojI9eHV6BwnjXldGkWHfFAuA0QL3ICYW uD7stDOcjaib8afwO7v5x3krtggWu92BoKIcSz8OGkoIyo7qYuNGMxp9RvBI56OvVZa+ 7DJtoMPtkJHh2hDgciagMbQg073x4VfhRkyvC2UJZUwmD0bBBUrtyumQAmB9kxBgWESu GPze0OOtqU6ZINfANMA3HbgifGCL+y9rS21Sw4j3lF789QCFaa11H0pCet9tf3pRvdOA 3vppTPyPKkISp98tzzs9DteRGtlBs6t7Ff9U3t5VmNNpZJZoXqBlPhbzi5h8zUVtU1wQ 6D8Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b=bV7bkn3z; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from lipwig.vger.email (lipwig.vger.email. [23.128.96.33]) by mx.google.com with ESMTPS id 19-20020a170902ee5300b001c572ccd45bsi4803132plo.391.2023.10.13.11.39.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 13 Oct 2023 11:39:49 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) client-ip=23.128.96.33; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b=bV7bkn3z; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by lipwig.vger.email (Postfix) with ESMTP id E881A806E3EE; Fri, 13 Oct 2023 11:39:46 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at lipwig.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229704AbjJMSjc (ORCPT + 99 others); Fri, 13 Oct 2023 14:39:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47712 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229518AbjJMSjb (ORCPT ); Fri, 13 Oct 2023 14:39:31 -0400 Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B8A58BB for ; Fri, 13 Oct 2023 11:39:29 -0700 (PDT) Received: by mail-ed1-x534.google.com with SMTP id 4fb4d7f45d1cf-51e24210395so1929a12.0 for ; Fri, 13 Oct 2023 11:39:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1697222368; x=1697827168; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=q2ohtkcvpEvo61Q68fjCDCwlB06zwFzfj4hgniJlyos=; b=bV7bkn3zxjUWqct4XFwbZ7Vpq8RtE+2stYHDshrwtA72XFDma4rBdOLGPyOkhVLPJj yeCzyiEUJhN4Z9s3AbVGHIBDMyWnIrOyE7bpUjFOWJxUfzWQkX0a4LC5QuOLFkBbqJNW wHxUmoJJ5PsYEOFpVo1m3KdyFj5EvQMvQuTL5H88s6OLmQhYfjsRBRcTPko+SaIWhxS5 Is2Ehzw9rBrP1iFEMTntuaCisp1Yx4JrBfpdORilXDkbF1bQLp8qR3kXTuBw0Hnnxz1u +HJ95vbbIyidkpk7B0p8G1kCfixTG2r2k5/9vF4De/V7NC9B4D9JztAlswnAxnpxZ3HR 4I3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697222368; x=1697827168; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=q2ohtkcvpEvo61Q68fjCDCwlB06zwFzfj4hgniJlyos=; b=fbgACHUtHTqKNG6zMIC3qKC8BYJ6Eem/jdM0sAXTC4DdT73fcB8uXZcwHZQBXTrTX0 3FJatQRvV+ohzUvAubuTVD2B/MJwm0rdcK0ewfLUevk2Bwu0SZ7cXw4heGdcxVicgiyW jnbzUeT8b/jWct69ykFpPmdJICDWafgmxappp06wUWV4JavZTnGp6DJT++AJB7l/oPAM ZWwJ5tibFZQesqaO0+5iPcnaaVY+Gw9pv0UQXqIF2f0rlo64ajOrApAaWrRbrwkte2FF KswPF7+tij46bgIZxwYJTHKrzg2n6gCMhTOHW5cadf96S/4DkURTHv+61FwZp1+UWgpZ KqHg== X-Gm-Message-State: AOJu0Yy11+Re0N5cRJQCuodhdquGd9/UwjBm070pMB3eOq6YeDJQ2ixC mQaR1y9WZlyjUyhK1nVsty80D8f8otIiyIvxEWXQVg== X-Received: by 2002:a50:a696:0:b0:52f:5697:8dec with SMTP id e22-20020a50a696000000b0052f56978decmr4174edc.4.1697222368058; Fri, 13 Oct 2023 11:39:28 -0700 (PDT) MIME-Version: 1.0 References: <20231009142005.21338-1-quic_kriskura@quicinc.com> <20231009142005.21338-2-quic_kriskura@quicinc.com> <8ff92053-52ff-4950-95c8-0e986f6a028a@quicinc.com> In-Reply-To: <8ff92053-52ff-4950-95c8-0e986f6a028a@quicinc.com> From: =?UTF-8?Q?Maciej_=C5=BBenczykowski?= Date: Fri, 13 Oct 2023 11:39:10 -0700 Message-ID: Subject: Re: [PATCH 2/2] usb: gadget: ncm: Add support to update wMaxSegmentSize via configfs To: Krishna Kurapati PSSNV Cc: Greg Kroah-Hartman , onathan Corbet , Linyu Yuan , linux-usb@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, quic_ppratap@quicinc.com, quic_wcheng@quicinc.com, quic_jackp@quicinc.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-8.4 required=5.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lipwig.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (lipwig.vger.email [0.0.0.0]); Fri, 13 Oct 2023 11:39:47 -0700 (PDT) On Thu, Oct 12, 2023 at 8:40=E2=80=AFAM Krishna Kurapati PSSNV wrote: > > > > On 10/12/2023 6:02 PM, Maciej =C5=BBenczykowski wrote: > > On Thu, Oct 12, 2023 at 1:48=E2=80=AFAM Krishna Kurapati PSSNV > > > > Could you paste the full patch? > > This is hard to review without looking at much more context then email > > is providing > > (or, even better, send me a link to a CL in gerrit somewhere - for > > example aosp ACK mainline tree) > > Sure. Will provide a gerrit on ACK for review before posting v2. > > The intent of posting the diff was two fold: > > 1. The question Greg asked regarding why the max segment size was > limited to 15014 was valid. When I thought about it, I actually wanted > to limit the max MTU to 15000, so the max segment size automatically > needs to be limited to 15014. Note that this is a *very* abstract value. I get you want L3 MTU of 10 * 1500, but this value is not actually meaningf= ul. IPv4/IPv6 fragmentation and IPv4/IPv6 TCP segmentation do not result in a trivial multiplication of the standard 1500 byte ethernet L3 MTU. Indeed aggregating 2 1500 L3 mtu frames results in *different* sized frames depending on which type of aggregation you do. (and for tcp it even depends on the number and size of tcp options, though it is often assumed that those take up 12 bytes, since that's the normal for Linux-to-Linux tcp connections) For example if you aggregate N standard Linux ipv6/tcp L3 1500 mtu frames, this means you have N frames: ethernet (14) + ipv6 (40) + tcp (20) + tcp options (12) + payload (1500-12-20-40=3D1500-72=3D1428) post aggregation: 1 frame: ethernet (14) + ipv6 (40) + tcp (20) + tcp options (12) + payload (N*1428) so N * 1500 =3D=3D N * (72 + 1428) --> 1 * (72 + N * 1428) That value of 72 is instead 52 for 'standard Linux ipv4/tcp), it's 40/60 if there's no tcp options (which I think happens when talking to windows) it's different still with ipv4 fragmentation... and again different with ipv6 fragmentation... etc. ie. 15000 L3 mtu is exactly as meaningless as 14000 L3 mtu. Either way you don't get full frames. As such I'd recommend going with whatever is the largest mtu that can be meaningfully made to fit in 16K with all the NCM header overhead. That's likely closer to 15500-16000 (though I have *not* checked). > But my commit text didn't mention this > properly which was a mistake on my behalf. But when I looked at the > code, limiting the max segment size 15014 would force the practical > max_mtu to not cross 15000 although theoretical max_mtu was set to: > (GETHER_MAX_MTU_SIZE - 15412) during registration of net device. > > So my assumption of limiting it to 15000 was wrong. It must be limited > to 15412 as mentioned in u_ether.c This inturn means we must limit > max_segment_size to: > GETHER_MAX_ETH_FRAME_LEN (GETHER_MAX_MTU_SIZE + ETH_HLEN) > as mentioned in u_ether.c. > > I wanted to confirm that setting MAX_DATAGRAM_SIZE to > GETHER_MAX_ETH_FRAME_LEN was correct. > > 2. I am not actually able to test with MTU beyond 15000. When my host > device is a linux machine, the cdc_ncm.c limits max_segment_size to: > CDC_NCM_MAX_DATAGRAM_SIZE 8192 /* bytes */ In practice you get 50% of the benefits of infinitely large mtu by going from 1500 to ~2980. you get 75% of the benefits by going to ~6K you get 87.5% of the benefits by going to ~12K the benefits of going even higher are smaller and smaller... If the host side is limited to 8192, maybe we should match that here too? But the host side limitation of 8192 doesn't seem particularly sane either.= .. Maybe we should relax that instead? (especially since for things like tcp zero copy you want an mtu which is slighly more then N * 4096, ie. around 4.5KB, 8.5KB, 12.5KB or something like that) > When connected to windows machine, I am able to set the mtu to a max > value of 15000. So not sure how to test the patch if I set the > max_segment_size to GETHER_MAX_ETH_FRAME_LEN. > > By pasting the diff, I wanted to confirm both the above queries. > > And you are right, while assigning value to ecm.wMaxSegmentSize, we must > use cpu_to_le16(...). Will ensure to make this change in v2. It worked > without that too, not sure how.