[U-Boot] TCP & Overrrun

Joe Hershberger joe.hershberger at ni.com
Fri Feb 9 21:11:29 UTC 2018


On Thu, Feb 8, 2018 at 8:41 PM, Duncan Hare <dh at synoia.com> wrote:
> On Thu, 8 Feb 2018 22:15:44 +0000 (UTC)
> Duncan Hare <dh at synoia.com> wrote:
>
>>  Duncan Hare
>>
>> 714 931 7952
>>
>>
>> ----- Forwarded Message -----
>>  From: Joe Hershberger <joe.hershberger at ni.com>
>>  To: Duncan Hare <dh at synoia.com>
>> Cc: u-boot <u-boot at lists.denx.de>; Joe Hershberger
>> <joe.hershberger at ni.com> Sent: Thursday, February 8, 2018 11:40 AM
>>  Subject: Re: [U-Boot] TCP & Overrrun
>>
>> Hi Duncan,
>>
>> On Wed, Feb 7, 2018 at 8:40 PM, Duncan Hare <dh at synoia.com> wrote:
>> > I'm gettin overrun on the raspberry pi.
>> >
>> > Which ethernet drived does it use?
>>
>> You didn't specify which one you are talking about, but here's how to
>> find out...
>>
>> Assuming rpi3, find the config first...
>>
>> configs/rpi_3_defconfig says:
>> CONFIG_DEFAULT_DEVICE_TREE="bcm2837-rpi-3-b"
>> arch/arm/dts/bcm2837-rpi-3-b.dts says: #include
>> "bcm283x-rpi-smsc9514.dtsi" arch/arm/dts/bcm283x-rpi-smsc9514.dtsi
>> says:                ethernet: usbether at 1 {
>> compatible = "usb424,ec00"; grep -rn ec00 drivers/ says:
>> drivers/usb/eth/smsc95xx.c
>>
>> Cheers,
>> -Joe
>>
>> > I need to determine if it
>> > uses CONFIG_SYS_RX_ETH_BUFFER" from net.h and the "net_rx_packets"
>> > buffer pool defined in net/net.c
>> >
>> > grep suggests it is not using net_rx_packets.
>> >
>> > Thanks
>> >
>> > Duncan Hare
>> > _______________________________________________
>> > U-Boot mailing list
>> > U-Boot at lists.denx.de
>> > https://lists.denx.de/listinfo/u-boot
> ___________________________________________________
> Joe
>
> Two solutions:
>
> Option 1.
>
> drivers/usb/eth/smsc95xx.c pulls packet in from the device, single rx buffer, and runs the packet
> rx code in net.c. Assumption is packets are polled for, thus single
> rx buffer is acceptable.
>
> net_rx_packets exists, and can be use, if looking for rx packet call
> is called frequently though system.
>
> This would work for all existing drivers.
>
> net.c fills net_rx_packets and calls a routine to process packets, and
> and the tcp system system polls via smsc95xx_recv through the interface
> structure at places in the code to process fill net_rx_packets as a
> packet queue.
>
> A TCP window limits the number of packets in process.
>
> Option 2.
>
> The driver is changed to set an interrupt and the interrupt
> preempts the packet processing, as interrupts do.

In general, we don't enable interrupts in U-Boot. There have been
exceptions, but not when there is a reasonable alternative.

> But, this requires driver changes to use TCP.
>
> And good hardware documentation.
>

I think option 1 is the way to go.

Thanks,
-Joe


More information about the U-Boot mailing list