From owner-freebsd-arm@freebsd.org Tue Nov 3 08:19:18 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 5EFCB45038F; Tue, 3 Nov 2020 08:19:18 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4CQN3n10WZz4l5D; Tue, 3 Nov 2020 08:19:16 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2020.home.selasky.org (unknown [178.17.145.105]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 82E582600E0; Tue, 3 Nov 2020 09:19:07 +0100 (CET) Subject: Re: Problem with checksum offloading on RPi3 (PF + Jails involved) To: YongHyeon PYUN , Kristof Provost Cc: John-Mark Gurney , =?UTF-8?Q?Carsten_B=c3=a4cker?= , freebsd-hackers@freebsd.org, freebsd-arm@freebsd.org 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> From: Hans Petter Selasky Message-ID: <46d08198-530c-cb4b-efa8-4edaf89471c1@selasky.org> Date: Tue, 3 Nov 2020 09:19:05 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20201103045215.GA2524@michelle> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4CQN3n10WZz4l5D X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-2.10 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net]; NEURAL_HAM_LONG(-1.02)[-1.023]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; ARC_NA(0.00)[]; RCPT_COUNT_FIVE(0.00)[6]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.19)[0.185]; NEURAL_HAM_MEDIUM(-0.96)[-0.964]; FREEMAIL_TO(0.00)[gmail.com,FreeBSD.org]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE]; FREEMAIL_CC(0.00)[funkthat.com,gmx.de,freebsd.org]; MAILMAN_DEST(0.00)[freebsd-arm,freebsd-hackers]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2020 08:19:18 -0000 On 2020-11-03 05:52, YongHyeon PYUN wrote: > On Thu, Oct 29, 2020 at 10:39:39PM +0100, Kristof Provost wrote: > > [...] > >> It does seem to do RX offload, and the comments in the driver suggest some >> .. ahem, creative hardware behaviour: >> >> /* The checksum appears to be simplistically calculated >> * over the udp/tcp header and data up to the end of the >> * eth frame. Which means if the eth frame is padded >> * the csum calculation is incorrectly performed over >> * the padding bytes as well. Therefore to be safe we >> * ignore the H/W csum on frames less than or equal to >> * 64 bytes. >> * >> * Ignore H/W csum for non-IPv4 packets. >> */ >> >> It’s not impossible that there’s some more issues like that in the hardware, >> or even that there are different chip revisions out there. >> >> That also matches up with `ifconfig ue0 -rxcsum` fixing things. >> > > I'm not sure where the root cause is but it seems smsc(4) needs > improvement in RX checksum handling. Quick reading RX handler > indicates RX checksum offloading does not work when: > o IP datagram has IP options field > o TCP/UDP packet was fragmented > o UDP datagrams with 0 checksum value > See fxp(4), gem(4) and hme(4) for implementation. > > It looks like smsc(4) uses the following RX format but I don't > know actual RX format of H/W(no access to datasheet). > > <---------------------------- actlen --------------------------------------------------> > <------------- pktlen ------------------------> > rxhdr(4 bytes) | padding (2 bytes) | RX frame | FCS(4 bytes) | partial checksum(2 bytes) > > If the format above is correct smsc(4) needs more strict RX length > validation(USB transfer size vs actual packet length). This > indicates smsc(4) does not have to copy FCS bytes. > Also given that H/W always appends FCS, it's also suspicious H/W > does not correctly compute RX checksum for frames less than or > equal to 64 bytes. > > I don't have H/W and some spare time to fix this though. :-( I can review and test patches. Seems like there is need for a fix. --HPS