From owner-freebsd-arm@freebsd.org Mon Nov 16 01:16:23 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 36CEF46EA46; Mon, 16 Nov 2020 01:16:23 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CZB3p1SDVz3vx9; Mon, 16 Nov 2020 01:16:21 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by mail-pf1-x42e.google.com with SMTP id 10so12206103pfp.5; Sun, 15 Nov 2020 17:16:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=UN5mwYYOvQhMlPDJBAGdGRMA71zPSShItFYE3dmsy7Y=; b=Fkngjd6lPSgRVV9rpkYNXnpBfOptwzpGOFBb9FAIErI/qzYLs4yRkdEw0+pS8iCGCA QxJ8yUiE/SQjz0qJd8XlvXnVmxpxjtlQ96+C088CzoOApWVi/KQhTaC3yvPSVSSf7XuK oI+smowIrI5aygJIDzbd0PLhnWqJgWYQBlPCXyHmczof9oG8O3A8wQJvZ2r+ThyTkRlD w7/Kp/6BxBxFKDlKlqn2Ix6V/qcW7X0HNRcwT2d1I6SDknQx0f/+0a47+nzM5Nw2P7fb 05Vw21qFAZ/3QN1QryryeqpOGJCKm4jUsXMbjdiSC/YruPUWWmikDB1HUv2O1GvXi3KG QLcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=UN5mwYYOvQhMlPDJBAGdGRMA71zPSShItFYE3dmsy7Y=; b=pJoBuBjvzTRyXf3NDQX8wiZo/t1HXGnRvqG+f2mdfbJ1JOd7E7ajGM9Pz3ohC4izTQ Gq0GuIyMoVbKwN01w5UiJd4I5ci9bpqpCtvNiO0xH8Vz/IIZp5bOftqDfkdt+dIeMDxr jK2VQniTGxH4YJaXhf6C0YSdHWpKb/SuicH7tQsvoMvUmsMHojQRr2rzaoAcSzmcjgYx R96cpGYnzutDAl8I2wCWvuyKQRETvH4xspqjtqUU1bWJZgzM9Y6vxMzOr/2U4/D6IO8n F180TOqU0TBbAl+G5glpG0Yofcl0yZEJDjRJZv0J8A013anqzyVfDuGSCfcybQQTHoz1 UNwQ== X-Gm-Message-State: AOAM531LEgRZhFpPeRb9EDHWMzyxFkTrdQ8pfwGDBfW3OWr7dpVssV/g hTLxLZ5NE63g7DxTc8Nv1sk= X-Google-Smtp-Source: ABdhPJzdE5+AEZhxHlvmBRVptniYkgWKxtoCi0fxxVmkAGGbmatxztAKHeRuY8KwkGE5+LRo/BuYCw== X-Received: by 2002:a17:90a:3cc4:: with SMTP id k4mr6662177pjd.106.1605489380127; Sun, 15 Nov 2020 17:16:20 -0800 (PST) Received: from localhost ([210.108.244.139]) by smtp.gmail.com with ESMTPSA id y5sm15583678pjr.50.2020.11.15.17.16.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 15 Nov 2020 17:16:18 -0800 (PST) Date: Mon, 16 Nov 2020 10:16:16 +0900 From: YongHyeon PYUN To: Lowell Gilbert Cc: freebsd-hackers@freebsd.org, freebsd-arm@freebsd.org Subject: Re: Problem with checksum offloading on RPi3 (PF + Jails involved) Message-ID: <20201116011616.GA1941@michelle> References: <748edc3d-4ef7-c4de-291f-7c0b460a6052@gmx.de> <5130ee46-5832-d4df-d774-c6bd32e10b30@gmx.de> <20201029213622.GM31099@funkthat.com> <55713894-A896-4F12-ABB9-93DFEB2F16B9@FreeBSD.org> <20201103045215.GA2524@michelle> <44zh3ybd0s.fsf@Be-Well.Ilk.Org> <20201104013017.GA48398@michelle> <44eel9bv5k.fsf@Be-Well.Ilk.Org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44eel9bv5k.fsf@Be-Well.Ilk.Org> X-Rspamd-Queue-Id: 4CZB3p1SDVz3vx9 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=Fkngjd6l; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of pyunyh@gmail.com designates 2607:f8b0:4864:20::42e as permitted sender) smtp.mailfrom=pyunyh@gmail.com X-Spamd-Result: default: False [-3.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[2607:f8b0:4864:20::42e:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; 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=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[2607:f8b0:4864:20::42e:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::42e:from]; MID_RHS_NOT_FQDN(0.50)[]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers,freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 01:16:23 -0000 On Tue, Nov 03, 2020 at 11:31:03PM -0500, Lowell Gilbert wrote: > YongHyeon PYUN writes: > > > On Tue, Nov 03, 2020 at 11:50:27AM -0500, Lowell Gilbert wrote: [...] > > Sorry, but I only have the public data sheet currently. > http://ww1.microchip.com/downloads/en/devicedoc/ds_lan89530_60001347a.pdf > Oh, thanks a lot. > > FreeBSD's USB stack requires copy operation for received frames so > > driver does not need any padding in RX path and ethernet frame > > alignment in mbuf can be adjusted in the copy operation. Since > > FCS bytes have no use in upper stack at this moment, it would be > > even better to strip FCS if there is way to do that in H/W. > > As I read this, the FCS is stripped if the padding is, but if you do > that, you have to disable the IP RX checksum offloading. > That's the note at the bottom of page 71. > Yup, found it. > I think the padding after the status word is strictly to word-align the > frame start, so you seem to have what you're looking for. > > The pre-frame padding is set by a Hardware Configuration Register. > Yes it seems, I disabled it in my patch as it is not required. > > For TX checksum offloading support, we need more information on > > H/W's TX handling(TX_CTRL_0 and TX_CTRL_1) too. I guess it needs > > special magic sequence of programming(i.e. existence of > > SMSC_TX_CTRL_0_FIRST_SEG and SMSC_TX_CTRL_0_LAST_SEG) but it could > > be greatly simplified to program the H/W for TX checksum offloading > > since driver also have to copy entire mbuf chain to USB stack(i.e > > single big TX segment for the H/W). > > The scatter-gather handling is driven from the first and last segment > flags, but the checksum addition *seems* to just happen by magic if the > checksum enable flag is also set. According to this data sheet, the > checksum enable flag has no effect except on the first segment, but > setting it the same way in every segment would be prudent. > > I have no idea if all of the chips under this driver use the same > command word formats, but they probably do. > Linux driver seems to have no special handling on other revisions so I think you're right. The real issue in TX checksum offloading is workaround for H/W limitation(bug?). It looks like H/W does not correctly compute checksum when checksum insertion offset is in the last 4 bytes of the TX packet which would be the case for pure-TCP ACK segments. For UDP case, we probably can't enable checksum offloading since the H/W is not smart enough to change UDP checksum value to 0xffff. > My experience is several years ago, and I have no hardware to try things > out on... Me too. :-(