From owner-freebsd-current@FreeBSD.ORG Fri Aug 30 01:46:33 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7292D9CE for ; Fri, 30 Aug 2013 01:46:33 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4BB012983 for ; Fri, 30 Aug 2013 01:46:33 +0000 (UTC) Received: by mail-pa0-f44.google.com with SMTP id fz6so1671047pac.17 for ; Thu, 29 Aug 2013 18:46:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:subject:message-id:reply-to:mime-version:content-type :content-disposition:user-agent; bh=DIoEP1et5As0cJIQgXz90iPBRXA7J1zjZGSXLPNzrpk=; b=nkzDHc4OYfGVAe0ztyZ/+tYhPTH9Y2Rt8xLCl2tJ/wMlIvz+g07N/RW+QgYvhLC48h UL7Rnd7rts3zNijlHpY+7OkScrgnc/MF3r6wHNC3Z8v68fUgNhcmP0mZYm37c6W2yh8/ mUjTAcC86hy5RXZEm4/1DYc5DvwCMoU0AbeuWjN7+P+7kL8xosOcRPS3FZDzGzcYG4Jy vLOV3LyGnqYm36YeKxCZvPHuTzz9dvI0B5Ibsx5uabWvALmd/rDy15noogn7/oWp2w13 hR5pbCeBPmXR7MabQFqO1LASfWhsxRVhF8GSoznGphL1rUNW3s8GTt+xUklM40J/r85Q rB7Q== X-Received: by 10.68.143.38 with SMTP id sb6mr6902012pbb.44.1377827192994; Thu, 29 Aug 2013 18:46:32 -0700 (PDT) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPSA id ct4sm31806722pbb.41.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 29 Aug 2013 18:46:32 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 30 Aug 2013 10:46:26 +0900 From: Yonghyeon PYUN Date: Fri, 30 Aug 2013 10:46:26 +0900 To: freebsd-current@FreeBSD.org Subject: CFT: bge(4) TX/RX checksum offloading Message-ID: <20130830014626.GA3107@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 01:46:33 -0000 Hi, It was known that bge(4) generated wrong TCP/UDP checksum when the frame length was less then 60 bytes. So bge(4) implemented padding workaround for such runt frames. bge(4) also ignored H/W assisted TCP/UDP checksum result when the length of received frame was less than 60 bytes. This workaround came from NetBSD about 7 years ago. Recently I started to wonder why bge(4) needs such workaround given that 1) publicly available data sheet does not mention the issue and 2) Linux tg3 does not have any workaround for the issue. I also asked the question to Broadcom and I was told that they(both Linux and Windows software developers) can't recall they have the issue. Linux does not use IP checksum offloading feature of controller so it's possible for the controller to have IP checksum offloading issue on runt frames. But I was not able to reproduce the issue on my box. Here is the patch that removes the workaround in bge(4). http://people.freebsd.org/~yongari/bge/bge.csum.diff The diff was generated against HEAD but it will also apply cleanly to stable/9. If you use bge(4) devices, please give it a whirl and let me know how well it works on your configuration. Thanks.