From owner-freebsd-arm@freebsd.org Tue Nov 3 08:46:12 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 8F2C6450DF0; Tue, 3 Nov 2020 08:46:12 +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 4CQNfq6JYSz4nXC; Tue, 3 Nov 2020 08:46:11 +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 A99212600E0; Tue, 3 Nov 2020 09:46:09 +0100 (CET) Subject: Re: Problem with checksum offloading on RPi3 (PF + Jails involved) From: Hans Petter Selasky To: YongHyeon PYUN , Kristof Provost Cc: freebsd-arm@freebsd.org, freebsd-hackers@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> <46d08198-530c-cb4b-efa8-4edaf89471c1@selasky.org> Message-ID: <4dfaa9a3-c085-8466-a6e4-19f988b5ed3d@selasky.org> Date: Tue, 3 Nov 2020 09:46:08 +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: <46d08198-530c-cb4b-efa8-4edaf89471c1@selasky.org> Content-Type: multipart/mixed; boundary="------------812ED0F32473780BBAF6ADAC" Content-Language: en-US X-Rspamd-Queue-Id: 4CQNfq6JYSz4nXC 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.23 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[multipart/mixed,text/plain,text/x-patch]; HAS_ATTACHMENT(0.00)[]; DMARC_NA(0.00)[selasky.org]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.17)[0.168]; NEURAL_HAM_LONG(-1.03)[-1.031]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.07)[-1.067]; FREEMAIL_TO(0.00)[gmail.com,FreeBSD.org]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+]; ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm,freebsd-hackers] 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:46:12 -0000 This is a multi-part message in MIME format. --------------812ED0F32473780BBAF6ADAC Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 2020-11-03 09:19, Hans Petter Selasky wrote: > 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) Hi, I wonder if the checksum is zero, when not valid, and that we should check for this in the driver! Can you try this patch? Also enabling debugging in the SMSC driver would be useful. --HPS --------------812ED0F32473780BBAF6ADAC Content-Type: text/x-patch; charset=UTF-8; name="smsc.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="smsc.diff" Index: sys/dev/usb/net/if_smsc.c =================================================================== --- sys/dev/usb/net/if_smsc.c (revision 367268) +++ sys/dev/usb/net/if_smsc.c (working copy) @@ -1020,7 +1020,7 @@ pktlen -= 2; /* The checksum appears to be simplistically calculated - * over the udp/tcp header and data up to the end of the + * 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 @@ -1031,27 +1031,21 @@ */ if ((be16toh(eh->ether_type) == ETHERTYPE_IP) && (pktlen > ETHER_MIN_LEN)) { - struct ip *ip; + /* Copy the TCP/UDP checksum from the last 2 bytes + * of the transfer and put in the csum_data field. + */ + usbd_copy_out(pc, (off + pktlen), &m->m_pkthdr.csum_data, 2); - ip = (struct ip *)(eh + 1); - if ((ip->ip_v == IPVERSION) && - ((ip->ip_p == IPPROTO_TCP) || - (ip->ip_p == IPPROTO_UDP))) { + /* The data is copied in network order, but the + * csum algorithm in the kernel expects it to be + * in host network order. + */ + m->m_pkthdr.csum_data = ntohs(m->m_pkthdr.csum_data); + + if (m->m_pkthdr.csum_data != 0) { /* Indicate the UDP/TCP csum has been calculated */ m->m_pkthdr.csum_flags |= CSUM_DATA_VALID; - /* Copy the TCP/UDP checksum from the last 2 bytes - * of the transfer and put in the csum_data field. - */ - usbd_copy_out(pc, (off + pktlen), - &m->m_pkthdr.csum_data, 2); - - /* The data is copied in network order, but the - * csum algorithm in the kernel expects it to be - * in host network order. - */ - m->m_pkthdr.csum_data = ntohs(m->m_pkthdr.csum_data); - smsc_dbg_printf(sc, "RX checksum offloaded (0x%04x)\n", m->m_pkthdr.csum_data); } --------------812ED0F32473780BBAF6ADAC--