From mboxrd@z Thu Jan 1 00:00:00 1970 From: Piotr =?iso-8859-2?q?Zi=EAcik?= Date: Thu, 16 Jul 2009 15:32:48 +0200 Subject: [U-Boot] [PATCH] eth_receive(): Do not assume that caller always wants full packet. In-Reply-To: <20090716123959.F3E34832E416@gemini.denx.de> References: <1247558915-26591-1-git-send-email-kosmo@semihalf.com> <200907161151.59353.kosmo@semihalf.com> <20090716123959.F3E34832E416@gemini.denx.de> Message-ID: <200907161532.49054.kosmo@semihalf.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Thursday 16 July 2009 14:39:59 Wolfgang Denk napisa?(a): > > But recv() is on another level. Here we are dealing with receiving raw > ethernet frames. > I think that there is an analogy. Both function could be used for receiving _frames_. eth_receive() for ethernet frames and Linux recv() for UDP frames. > > function. I do not see why we have to force application to prepare 1,5kB > > buffer for received packets when for example it waits for ARP reply. > > Come on - what exactly is the extra effort you have to spend to > prepare a bigger buffer? > Maybe I have used bad example. When application prepares a buffer and chooses it's size to be less than interface MTU it means that application is not able to process larger packets. U-Boot should not expect that simple application using API is able to handle every possible case (for example 9k packets on gigabyte ethernet). -- Pozdrawiam. Piotr Zi?cik