From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S941199AbcKXTKm (ORCPT ); Thu, 24 Nov 2016 14:10:42 -0500 Received: from pb-sasl2.pobox.com ([64.147.108.67]:65158 "EHLO sasl.smtp.pobox.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757058AbcKXTKk (ORCPT ); Thu, 24 Nov 2016 14:10:40 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=subject:to :references:cc:from:message-id:date:mime-version:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=MjaAtd gtqMwPe2JEp9myABDxWwYDtA9wAoWr7MZZgYBVlwd2wz1xReRz8mCswdHMSM+9z5 BcS8nAmeZpD1j74Vk4nX5p38gBSa8d0M1i+eoRSxz3hjMWntoe+e20iU9vpiv+w9 hRL9cL2P0642/KqKLmudSrKCYuBqd3A8q7Siw= Subject: Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable To: Greg KH 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> <20161124190055.GA3642@kroah.com> Cc: David Miller , hayeswang@realtek.com, netdev@vger.kernel.org, nic_swsd@realtek.com, linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org From: Mark Lord Message-ID: <9e8ff5b4-1c72-3106-7821-73484de133c2@pobox.com> Date: Thu, 24 Nov 2016 14:10:36 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161124190055.GA3642@kroah.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: AF936E30-B279-11E6-BED6-7471F2301B6D-82205200!pb-sasl2.pobox.com Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 16-11-24 02:00 PM, Greg KH wrote: > 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? Exactly my point. > Check the zero-packet stuff for this device, that's tripped up many a > USB driver writer over the years, myself included. I haven't tripped over it myself, but only because we were careful to allow for such in the USB drivers I have worked on. The r8152 driver just assumes it never happens.