Date: Mon, 16 Nov 2020 10:16:16 +0900 From: YongHyeon PYUN <pyunyh@gmail.com> To: Lowell Gilbert <Lowell@Be-Well.Ilk.Org> 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> In-Reply-To: <44eel9bv5k.fsf@Be-Well.Ilk.Org> References: <748edc3d-4ef7-c4de-291f-7c0b460a6052@gmx.de> <D8CE4762-4D94-47C7-A8D1-6C537766813B@FreeBSD.org> <5130ee46-5832-d4df-d774-c6bd32e10b30@gmx.de> <A3890336-BE8F-438C-8C3E-7B21FB729FCA@FreeBSD.org> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Nov 03, 2020 at 11:31:03PM -0500, Lowell Gilbert wrote: > YongHyeon PYUN <pyunyh@gmail.com> 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. :-(
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20201116011616.GA1941>