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@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@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.
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@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@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
participants (2)
-
Duncan Hare -
Joe Hershberger