[U-Boot] TCP & Overrrun

[U-Boot] TCP & Overrrun

[Duncan Hare]

I'm gettin overrun on the raspberry pi.

Which ethernet drived does it use? 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.

Here's a list of a grep of the u-boot source directory

rch/mips/mach-au1x00/au1x00_eth.c
arch/powerpc/cpu/mpc85xx/ether_fcc.c
net/net.c
drivers/usb/gadget/ether.c
drivers/net/ep93xx_eth.c
drivers/net/cs8900.c
drivers/net/ftgmac100.c
drivers/net/ks8851_mll.c
drivers/net/dc2114x.c
drivers/net/dm9000x.c
drivers/net/xilinx_ll_temac_fifo.c
drivers/net/ax88180.c
drivers/net/tsec.c
drivers/net/mcffec.c
drivers/net/dnet.c
drivers/net/ftmac100.c
drivers/net/xilinx_ll_temac_sdma.c
drivers/net/sandbox-raw.c
drivers/net/cpsw.c
drivers/net/sandbox.c
drivers/net/smc911x.c
drivers/net/lan91c96.c
drivers/net/uli526x.c
drivers/net/tsi108_eth.c
drivers/net/mpc8xx_fec.c
drivers/net/at91_emac.c
drivers/net/ethoc.c
drivers/net/fsl_mcdmafec.c
drivers/net/bcm-sf2-eth.c
drivers/net/enc28j60.c
drivers/net/smc91111.c
drivers/net/macb.c
drivers/net/pic32_eth.c

Thanks

Duncan Hare

[U-Boot] TCP & Overrrun

[Joe Hershberger]

Hi Duncan,

On Wed, Feb 7, 2018 at 8:40 PM, Duncan Hare <dh@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.
>
> Here's a list of a grep of the u-boot source directory
>
> rch/mips/mach-au1x00/au1x00_eth.c
> arch/powerpc/cpu/mpc85xx/ether_fcc.c
> net/net.c
> drivers/usb/gadget/ether.c
> drivers/net/ep93xx_eth.c
> drivers/net/cs8900.c
> drivers/net/ftgmac100.c
> drivers/net/ks8851_mll.c
> drivers/net/dc2114x.c
> drivers/net/dm9000x.c
> drivers/net/xilinx_ll_temac_fifo.c
> drivers/net/ax88180.c
> drivers/net/tsec.c
> drivers/net/mcffec.c
> drivers/net/dnet.c
> drivers/net/ftmac100.c
> drivers/net/xilinx_ll_temac_sdma.c
> drivers/net/sandbox-raw.c
> drivers/net/cpsw.c
> drivers/net/sandbox.c
> drivers/net/smc911x.c
> drivers/net/lan91c96.c
> drivers/net/uli526x.c
> drivers/net/tsi108_eth.c
> drivers/net/mpc8xx_fec.c
> drivers/net/at91_emac.c
> drivers/net/ethoc.c
> drivers/net/fsl_mcdmafec.c
> drivers/net/bcm-sf2-eth.c
> drivers/net/enc28j60.c
> drivers/net/smc91111.c
> drivers/net/macb.c
> drivers/net/pic32_eth.c
>
> Thanks
>
> Duncan Hare
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot

[U-Boot] TCP & Overrrun

[dh at synoia.com]

On Thu, 8 Feb 2018 22:15:44 +0000 (UTC)
Duncan Hare <dh@synoia.com> wrote:

>  Duncan Hare
> 
> 714 931 7952
> 
>      
> ----- Forwarded Message -----
>  From: Joe Hershberger <joe.hershberger@ni.com>
>  To: Duncan Hare <dh@synoia.com> 
> Cc: u-boot <u-boot@lists.denx.de>; Joe Hershberger
> <joe.hershberger@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@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
> >
> > Thanks
> >
> > Duncan Hare
> > _______________________________________________
> > U-Boot mailing list
> > U-Boot at lists.denx.de
> > https://lists.denx.de/listinfo/u-boot  
> 
Joe

Thanks

It's is more push down stack buffer management than circular. Small
change to fix. No more starting at zero.

I like buffer pools with a size of power of 2. Easy to make circular
with an & of the power of 2-1 on the index.

Duncan

[U-Boot] TCP & Overrrun

[Duncan Hare]

On Thu, 8 Feb 2018 22:15:44 +0000 (UTC)
Duncan Hare <dh@synoia.com> wrote:

>  Duncan Hare
> 
> 714 931 7952
> 
>      
> ----- Forwarded Message -----
>  From: Joe Hershberger <joe.hershberger@ni.com>
>  To: Duncan Hare <dh@synoia.com> 
> Cc: u-boot <u-boot@lists.denx.de>; Joe Hershberger
> <joe.hershberger@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@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.

But, this requires driver changes to use TCP.

And good hardware documentation. 

   

[U-Boot] TCP & Overrrun

[Joe Hershberger]

On Thu, Feb 8, 2018 at 8:41 PM, Duncan Hare <dh@synoia.com> wrote:
> On Thu, 8 Feb 2018 22:15:44 +0000 (UTC)
> Duncan Hare <dh@synoia.com> wrote:
>
>>  Duncan Hare
>>
>> 714 931 7952
>>
>>
>> ----- Forwarded Message -----
>>  From: Joe Hershberger <joe.hershberger@ni.com>
>>  To: Duncan Hare <dh@synoia.com>
>> Cc: u-boot <u-boot@lists.denx.de>; Joe Hershberger
>> <joe.hershberger@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@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

[U-Boot] TCP & Overrrun

[Duncan Hare]

On Sun, 11 Feb 2018 00:39:05 +0000 (UTC)
Duncan Hare <dh@synoia.com> wrote:

>  Duncan Hare
> 
> 714 931 7952
> 
>      
> ----- Forwarded Message -----
>  From: Joe Hershberger <joe.hershberger@ni.com>
>  To: Duncan Hare <dh@synoia.com> 
> Cc: Joe Hershberger <joe.hershberger@ni.com>; u-boot
> <u-boot@lists.denx.de> Sent: Friday, February 9, 2018 1:11 PM
>  Subject: Re: [U-Boot] TCP & Overrrun
>    
> On Thu, Feb 8, 2018 at 8:41 PM, Duncan Hare <dh@synoia.com> wrote:
> > On Thu, 8 Feb 2018 22:15:44 +0000 (UTC)
> > Duncan Hare <dh@synoia.com> wrote:
> >  
> >>  Duncan Hare
> >>
> >> 714 931 7952
> >>
> >>
> >> ----- Forwarded Message -----
> >>  From: Joe Hershberger <joe.hershberger@ni.com>
> >>  To: Duncan Hare <dh@synoia.com>
> >> Cc: u-boot <u-boot@lists.denx.de>; Joe Hershberger
> >> <joe.hershberger@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@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.
> >  
> 
> I think option 1 is the way to go.
> 
> Thanks,
> -Joe

Joe

The overruns were caused by printing error messages. The print
process is (very) slow compared with packet and computer speeds, and
causes overruns.

I turned off all the error messages in tcp.c and the overruns also
stopped.

Makes debugging harder.

Duncan

[U-Boot] TCP & Overrrun

[Joe Hershberger]

Hi Duncan,

On Sat, Feb 10, 2018 at 6:44 PM, Duncan Hare <dh@synoia.com> wrote:
> On Sun, 11 Feb 2018 00:39:05 +0000 (UTC)
> Duncan Hare <dh@synoia.com> wrote:
>
>>  Duncan Hare
>>
>> 714 931 7952
>>
>>
>> ----- Forwarded Message -----
>>  From: Joe Hershberger <joe.hershberger@ni.com>
>>  To: Duncan Hare <dh@synoia.com>
>> Cc: Joe Hershberger <joe.hershberger@ni.com>; u-boot
>> <u-boot@lists.denx.de> Sent: Friday, February 9, 2018 1:11 PM
>>  Subject: Re: [U-Boot] TCP & Overrrun
>>
>> On Thu, Feb 8, 2018 at 8:41 PM, Duncan Hare <dh@synoia.com> wrote:
>> > On Thu, 8 Feb 2018 22:15:44 +0000 (UTC)
>> > Duncan Hare <dh@synoia.com> wrote:
>> >
>> >>  Duncan Hare
>> >>
>> >> 714 931 7952
>> >>
>> >>
>> >> ----- Forwarded Message -----
>> >>  From: Joe Hershberger <joe.hershberger@ni.com>
>> >>  To: Duncan Hare <dh@synoia.com>
>> >> Cc: u-boot <u-boot@lists.denx.de>; Joe Hershberger
>> >> <joe.hershberger@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@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.
>> >
>>
>> I think option 1 is the way to go.
>>
>> Thanks,
>> -Joe
>
> Joe
>
> The overruns were caused by printing error messages. The print
> process is (very) slow compared with packet and computer speeds, and
> causes overruns.
>
> I turned off all the error messages in tcp.c and the overruns also
> stopped.

You could probably make the printing buffered (maybe just turn on such
a thing) to speed it up. You can also have different log levels to
turn on different traces so you can reduce the load for printing.

> Makes debugging harder.
>
> Duncan
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot

[U-Boot] TCP Patch Set

[Duncan Hare]

On Mon, 12 Feb 2018 13:35:11 -0600
Joe Hershberger <joe.hershberger@ni.com> wrote:


> >> >>  
> >> >> > 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
> >> >> >

> >> >
> >> > Two solutions:
> >> >
> >> > Option 1.
> >> >  
> >>
> >> I think option 1 is the way to go.
> >>
> >> Thanks,
> >> -Joe  
> >
> > Joe
> >
> > The overruns were caused by printing error messages. The print
> > process is (very) slow compared with packet and computer speeds, and
> > causes overruns.
> >
> > I turned off all the error messages in tcp.c and the overruns also
> > stopped.  

> >
> > Duncan
-----------------------------------------------------------------------
Joe

I'm now at the state where I'm satisfied the selective
acknowledgment implementation is working well, having re-written the
code.

I've transferred 20 4 Mbyte kernels from cloud to desktop without a
failure. 

How to proceed?

Issue the patch set again? Or just the TCP module?

Then what's the next step?

Regards
Duncan

[U-Boot] TCP Patch Set

[Joe Hershberger]

Hi Duncan,

On Wed, Feb 21, 2018 at 6:39 PM, Duncan Hare <dh@synoia.com> wrote:
> On Mon, 12 Feb 2018 13:35:11 -0600
> Joe Hershberger <joe.hershberger@ni.com> wrote:
>
>
>> >> >>
>> >> >> > 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
>> >> >> >
>
>> >> >
>> >> > Two solutions:
>> >> >
>> >> > Option 1.
>> >> >
>> >>
>> >> I think option 1 is the way to go.
>> >>
>> >> Thanks,
>> >> -Joe
>> >
>> > Joe
>> >
>> > The overruns were caused by printing error messages. The print
>> > process is (very) slow compared with packet and computer speeds, and
>> > causes overruns.
>> >
>> > I turned off all the error messages in tcp.c and the overruns also
>> > stopped.
>
>> >
>> > Duncan
> -----------------------------------------------------------------------
> Joe
>
> I'm now at the state where I'm satisfied the selective
> acknowledgment implementation is working well, having re-written the
> code.
>
> I've transferred 20 4 Mbyte kernels from cloud to desktop without a
> failure.
>
> How to proceed?
>
> Issue the patch set again? Or just the TCP module?
>
> Then what's the next step?

I think the next step is to rework your patch submission process,
sending the patches to just yourself, until they meet the standard (
http://www.denx.de/wiki/U-Boot/Patches ) so that all of the tooling I
use can work with them. Otherwise I spend lots of time, sometimes
hours, trying to shove malformed patches through the process. I really
don't have time for that, so I have to ask that you use patman and
send properly formatted patches. Once you have that down, I'll
re-review what you have at this point and go from there.

Thanks,
-Joe