Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S941231AbcKXTAt (ORCPT ); Thu, 24 Nov 2016 14:00:49 -0500 Received: from out5-smtp.messagingengine.com ([66.111.4.29]:54360 "EHLO out5-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935957AbcKXTAr (ORCPT ); Thu, 24 Nov 2016 14:00:47 -0500 X-ME-Sender: X-Sasl-enc: rENlH9cwq+CLXkEOB15Rod/N1eD6+WS2L+l+vPgAmU0d 1480014045 Date: Thu, 24 Nov 2016 20:00:55 +0100 From: Greg KH To: Mark Lord Cc: David Miller , hayeswang@realtek.com, netdev@vger.kernel.org, nic_swsd@realtek.com, linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org Subject: Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Message-ID: <20161124190055.GA3642@kroah.com> References: <0835B3720019904CB8F7AA43166CEEB201055ED8@RTITMBSV03.realtek.com.tw> <20161124.112152.692025478489876693.davem@davemloft.net> <23e0c132-8844-0a34-3e0b-e412f76493ba@pobox.com> <20161124.121140.2054576632424977475.davem@davemloft.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 933 Lines: 20 On Thu, Nov 24, 2016 at 01:34:08PM -0500, Mark Lord wrote: > One thought: bulk data streams are byte streams, not packets. > Scheduling on the USB bus can break up larger transfers across > multiple in-kernel buffers. A "real" URB buffer on USB2 is max 512 bytes. > The driver is providing 16384-byte buffers, and assumes that data will > never spill over from one such buffer to the next. > Yet the observations here consistently show otherwise. Wait, how do you know that data will not spill over? What is making that guarantee? Will the USB device send a "zero packet" in order to show that all of the "logical" data is now sent for this specific endpoint? Is there some sort of "framing" that the device does with the USB data so that the driver "knows" where the end of packet is? Check the zero-packet stuff for this device, that's tripped up many a USB driver writer over the years, myself included. thanks, greg k-h