From nobody Wed Jan 19 14:02:35 2022 X-Original-To: freebsd-transport@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4187D1962DAD for ; Wed, 19 Jan 2022 14:02:54 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jf6mF3Xv3z3Dxv for ; Wed, 19 Jan 2022 14:02:53 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: by mail-pj1-x1035.google.com with SMTP id b1-20020a17090a990100b001b14bd47532so2774475pjp.0 for ; Wed, 19 Jan 2022 06:02:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=TFjt1sfpBVPbJYArYdS9utcMO6YoJrMYL4r7IpH5lek=; b=Ae3+IRRWPkVCnCHGu5LGV6xlq7mPHC2bW2EhadnDUVZdC7svRSUZ4Fcs5qWzQ1fC9k kdxsPerHeMj3jJqhkf1Sic18Y28PoSLh7IVMIsNm3aLrohS1oLDRk+tZ6G/n4SwvomEI b1gEv283eFlKigb5NFpQoiUNaSFW6IO9hmiww5xS9R+vScx5XxgSoThd9LidEODHT8a2 qE+27eJ2k9IKdpLpv2Rdh1jNaUo3mR4poZpejH5WBmOQrVxFTDn4L7idafhaphdHpiow Lxr8C860TTh7xX0olBReuuGqjsN1ak9H3syZcnM4wjAvogfTm1PUst6rnGOS7xaoaDI6 ofwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=TFjt1sfpBVPbJYArYdS9utcMO6YoJrMYL4r7IpH5lek=; b=yXJ/6M6uGdmyD8X/3QmX3PM0KMu6RGCT5k+1unywBfvUn0DiX/E3El3Pt+1h9GFerx 8b1N7WwcGmfp4xQJR3xUG7rUooRJwdyB9JWzQv4lXOBYQmAmncqw0j3b+KV1gzhF6U4V asJRtkiXI7VCXAgK9qB53y7n/yiM1KVp1oCO2WywLEcMZTncvOXsW1A1rbP+FAfk0E2B XQv9RuimOaHiqAcSu6rSR44iZPDka8u4RE+5KesJXQXAFbaf9QP5Ur4u3LJ+7ANoRMj6 GAFMC/dCVPMNKLH6//yEgtkhU2oAtQoShMRUIwygSCheD4LK8erskzmSH0BjMvDQKrRf HIGg== X-Gm-Message-State: AOAM530WysXTZ1h6yQJC9jczNmQBAgzeNBVmnn3ZWj4ztQlF17Pu/FCX DGJEiXLNhMgSY4/Eb/9P5z5iRPkMzafqMGg6FWyOr97D X-Google-Smtp-Source: ABdhPJylIm9NMUqAqmGvf/iTfodgyCdLOs5UJKvLyfwNlYiz0/IvF0zHCIqqWWgQVp34/QxkCB8PP5MQH+Isv6joYd8= X-Received: by 2002:a17:90b:33c7:: with SMTP id lk7mr4493646pjb.86.1642600966214; Wed, 19 Jan 2022 06:02:46 -0800 (PST) List-Id: Discussions List-Archive: https://lists.freebsd.org/archives/freebsd-transport List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-transport@freebsd.org X-BeenThere: freebsd-transport@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Ryan Stone Date: Wed, 19 Jan 2022 09:02:35 -0500 Message-ID: Subject: Re: How should TCP LRO handle TH_PUSH? To: "Scheffenegger, Richard" Cc: "" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4Jf6mF3Xv3z3Dxv X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=Ae3+IRRW; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rysto32@gmail.com designates 2607:f8b0:4864:20::1035 as permitted sender) smtp.mailfrom=rysto32@gmail.com X-Spamd-Result: default: False [-2.91 / 15.00]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.91)[-0.914]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-transport@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1035:from]; MLMMJ_DEST(0.00)[freebsd-transport]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N The current behaviour is that if a flag other than PUSH/ACK is set, the current aggregated frame is sent up the stack and it starts working on a new one that begins with the packet with the unusual flags. However my reading of the code is that a subsequent packet with only PUSH or ACK set could be merged into that one. On Wed, Jan 19, 2022 at 2:33 AM Scheffenegger, Richard wrote: > > As discussed in the last transport call, can you please share the behavio= r with other TCP flags as well? > > URG is mostly historic > > ECE is tricky - presumably the flag of the last (in-sequence) packet shou= ld take precedence without AccECN. With AccECN, the new codepath where LRO = provides the full sequence of all received header bits is preferred. > CWR should be latched - if any packet in the LRO has it, it should be kep= t > PSH should (conceptually) be latched, even though the FBSD stack doesn't = do anything with it - other than possibly triggering an immediate ACK (good= to reduce the dependency on the delayed ACK timer). > > What is the behavior for the other flags (FIN, RST, SYN)? > > Best regards, > Richard > > > -----Original Message----- > From: owner-freebsd-transport@freebsd.org On Behalf Of Ryan Stone > Sent: Freitag, 7. J=C3=A4nner 2022 00:10 > To: > Subject: How should TCP LRO handle TH_PUSH? > > NetApp Security WARNING: This is an external email. Do not click links or= open attachments unless you recognize the sender and know the content is s= afe. > > > > > I've been working on writing unit tests for LRO (see my message to freebs= d-testing@ for more details on this). I've submitted reviews for two issue= s found by my tests that I believe to be outright bugs. > I did find one more issue where I'm not sure whether it's really a bug or= not. If LRO sees a TCP packet that does not have TH_PUSH set, and then me= rges a subsequent packet that does have TH_PUSH set into it, what should th= e value of the TH_PUSH flag in the merged packet be? > > When I wrote my test I expected to see TH_PUSH set, but that isn't our cu= rrent behaviour. On the one hand I'm not sure that this is strictly correc= t, but on the other hand I don't think we do anything with TH_PUSH on a rec= eived packet anyway. I did code up a proposed fix for this, but I wanted t= o get feedback as to whether it's worth worrying about before sending the r= eview. Does anybody have any opinions? > > Thanks, > Ryan >