From nobody Sat Aug 12 00:07:16 2023 X-Original-To: dev-commits-src-main@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 4RN1FH1q0Fz4pxCg for ; Sat, 12 Aug 2023 00:07:31 +0000 (UTC) (envelope-from kevin.bowling@kev009.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 4RN1FG6m4wz4Lnm for ; Sat, 12 Aug 2023 00:07:30 +0000 (UTC) (envelope-from kevin.bowling@kev009.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x1035.google.com with SMTP id 98e67ed59e1d1-2693640dfa2so1451627a91.3 for ; Fri, 11 Aug 2023 17:07:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kev009.com; s=google; t=1691798849; x=1692403649; 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=6mrhiYCfBLOxIh98oLf7kXLXTp9saNhC41ZG4+LkiLM=; b=mWyNccBducJ0CwUscEnk/8X4Q7FciHrCpEg2Hbr0CRv9dsCE7gZiiGTQA//w3J4HqZ uwEUmXh1YGG63ZLTqJQmy5i0focft8eSDxiyZAYL9G9XhiXv4qfghA/7XIjUQ1YyCyzj +e5lWigZYHubF/XbIwLPcAIEoMLNJZAWvCzCo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691798849; x=1692403649; 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=6mrhiYCfBLOxIh98oLf7kXLXTp9saNhC41ZG4+LkiLM=; b=ZX0oCbI/QmmXBnLLYCTfIEXsuOmNFxGnGn0FSTSm+Ypj3oJ4+cY3qcbZUeEVc5reMT cYt+D4rwqr0ugl33sedLFkx0a4LB7vc8zk5EkbyUNcRHufBYxS4Brx1eF8pznOdTFz5L PHk5uRN9qm2eDgVXzE0Hf3vc9xqGqoh58ijBxWGAcs3z49HHv1PYaYkmgM5Dv3WueJzZ fo9FHCFAZP/43nFRjMyshD6+wDVRuWu3I/NCw88vn/FRZTLHYS4AvgmK9Hu7YveTB5He OA+zSJXf6cpRHsZN/kFACejevjVs0a5FrTSGOlyLcrLBenC2ikLV9mbSQ4y93Z7EHCiF GdMg== X-Gm-Message-State: AOJu0YxEr6EmtPaKTCwg+7fVeEbvpkfbFnktBgUt8zR5JQLJHDw6wAqQ 9BlEiLhIw/3wBevAb4MpxlCNq/yc83B1qolQFOcOzg== X-Google-Smtp-Source: AGHT+IHeRUGKc9d47yhQDLnx6eWA+URumrw+l6K3H57P4mVurQIHqomoPAW7HjWyGqiiGKwrbtD1IzuiQ5NynQ+QPo0= X-Received: by 2002:a17:90a:9dcb:b0:268:29a3:bd05 with SMTP id x11-20020a17090a9dcb00b0026829a3bd05mr2059292pjv.48.1691798848680; Fri, 11 Aug 2023 17:07:28 -0700 (PDT) List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-main@freebsd.org X-BeenThere: dev-commits-src-main@freebsd.org MIME-Version: 1.0 References: <202308112251.37BMpOnC064624@gitrepo.freebsd.org> In-Reply-To: <202308112251.37BMpOnC064624@gitrepo.freebsd.org> From: Kevin Bowling Date: Fri, 11 Aug 2023 17:07:16 -0700 Message-ID: Subject: Re: git: 5f11a33ceeb3 - main - if_vlan: do not enable LRO for bridge interaces To: Kristof Provost Cc: src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4RN1FG6m4wz4Lnm X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] I am wondering what is going on with this patch, it doesn't seem like a full fix. At the very least we should clean up the "can't disable some capabilities" message. I've been looking at this for a couple hours and am wondering what is going on in if_bridge.. it looks like it correctly loops over the interfaces and masks ifcaps it doesn't like using the interface's ioctl SIOCSIFCAP. A similar pattern is used in if_lagg. I don't see any issue there so far. I also don't see the SIOCSICAP ioctl failing nor did vixie's message report that. I checked on a cxgbe(9) bridged vlan setup I have and see this message "bridge0: can't disable some capabilities on vlan0: 0x400" So I am wondering if the bug is that if_vlan SIOCSIFCAP is disregarding the ioctl's request mask.. it is just blindly calling vlan_capabilities. Regards, Kevin On Fri, Aug 11, 2023 at 3:51=E2=80=AFPM Kristof Provost wr= ote: > > The branch main has been updated by kp: > > URL: https://cgit.FreeBSD.org/src/commit/?id=3D5f11a33ceeb385477cb22d9ad5= 941061c5a26be9 > > commit 5f11a33ceeb385477cb22d9ad5941061c5a26be9 > Author: Paul Vixie > AuthorDate: 2023-08-11 18:17:16 +0000 > Commit: Kristof Provost > CommitDate: 2023-08-11 22:50:37 +0000 > > if_vlan: do not enable LRO for bridge interaces > > If the parent interface is not a bridge and can do LRO and > checksum offloading on VLANs, then guess it may do LRO on VLANs. > False positive here cost nothing, while false negative may lead > to some confusions. According to Wikipedia: > > "LRO should not operate on machines acting as routers, as it breaks > the end-to-end principle and can significantly impact performance." > > The same reasoning applies to machines acting as bridges. > > PR: 254596 > MFC after: 3 weeks > --- > sys/net/if_vlan.c | 22 +++++++++++++++------- > 1 file changed, 15 insertions(+), 7 deletions(-) > > diff --git a/sys/net/if_vlan.c b/sys/net/if_vlan.c > index 6aa872a19364..92e4e4247e3d 100644 > --- a/sys/net/if_vlan.c > +++ b/sys/net/if_vlan.c > @@ -2067,14 +2067,22 @@ vlan_capabilities(struct ifvlan *ifv) > } > > /* > - * If the parent interface can do LRO and checksum offloading on > - * VLANs, then guess it may do LRO on VLANs. False positive here > - * cost nothing, while false negative may lead to some confusions= . > + * If the parent interface is not a bridge and can do LRO and > + * checksum offloading on VLANs, then guess it may do LRO on VLANs= . > + * False positive here cost nothing, while false negative may lead > + * to some confusions. According to Wikipedia: > + * > + * "LRO should not operate on machines acting as routers, as it br= eaks > + * the end-to-end principle and can significantly impact performan= ce." > + * > + * The same reasoning applies to machines acting as bridges. > */ > - if (p->if_capabilities & IFCAP_VLAN_HWCSUM) > - cap |=3D p->if_capabilities & IFCAP_LRO; > - if (p->if_capenable & IFCAP_VLAN_HWCSUM) > - ena |=3D p->if_capenable & IFCAP_LRO; > + if (ifp->if_bridge =3D=3D NULL) { > + if (p->if_capabilities & IFCAP_VLAN_HWCSUM) > + cap |=3D p->if_capabilities & IFCAP_LRO; > + if (p->if_capenable & IFCAP_VLAN_HWCSUM) > + ena |=3D p->if_capenable & IFCAP_LRO; > + } > > /* > * If the parent interface can offload TCP connections over VLANs= then >