From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Warren Date: Thu, 16 Jul 2009 10:32:21 -0700 Subject: [U-Boot] [PATCH] eth_receive(): Do not assume that caller always wants full packet. In-Reply-To: <200907151105.45474.vapier@gentoo.org> References: <1247558915-26591-1-git-send-email-kosmo@semihalf.com> <200907151105.45474.vapier@gentoo.org> Message-ID: <4A5F6425.6080600@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Mike Frysinger wrote: > On Tuesday 14 July 2009 04:08:35 Piotr Ziecik wrote: > >> When packets arrive on the interface that are larger than the buffer >> being passed to U-Boot from a standalone application, then the >> eth_receive() returns -1 and leaves the packet saved. The next call to >> eth_receive() will find that same packet and can fail for the exact same >> reason. A typical scenario is the loader doing ARP with a buffer of 66 >> bytes. The end result is that the ARP will fail and the loader panics. >> >> This patch fixes above problem by allowing partial packet read. >> > > seems like it could easily introduce incorrect behavior in existing > applications. the code also sounds a bit risky ... your change would mean > people could read the leading part, but the rest is lost ? > > probably better to add a new function with explicit semantics -- > eth_receive_partial() or something. > -mike > I've read this whole thread, but this seems the most appropriate place to respond. I don't like changing the behavior of an existing call to truncation from an error, since who knows what will break. Adding another call with different, documented behavior seems more appropriate. I agree with Wolfgang that this really needs to be simple and personally don't see the burdens involved in allocating full MTU-sized buffers, but obviously can't envision all usage scenarios. The talk of jumbo frames is currently moot, as the buffer size is fixed in U-boot @ 1518 (#define PKTSIZE 1518). This should probably be configurable, but that's another matter. regards, Ben