Re: Networking stack - Ethernet driver design

Tomasz Bursztyka

Hi Piotr,

1. Currently Ethernet drivers are by default initialized before the
networking stack (as set by CONFIG_ETH_INIT_PRIORITY). That's
going to be problematic for a zero-copy implementation of Ethernet
driver. Such driver will need to reserve during the initialization
phase a set of net data buffers where the incoming packets can be
stored. Later when the complete frame is received these buffers
will be passed to the higher layer. However, the net buffer pool
is initialized by the networking stack so reserving net buffers is
only possible after networking stack was initialized. That implies
that the Ethernet driver should be initialized after the
networking stack. Secondly, even in case of the more typical
implementation of the Ethernet driver, the one which has its own
set of RX/TX buffers and copies data between them and net buffers,
as currently done in Zephyr, the driver will start working
immediately after being initialized. If it receives a frame just
at that moment it will try to pass it to the higher layer even if
the rest of the networking stack was not yet initialized. Once
again that implies that the Ethernet driver should be initialized
after the networking stack is.
You are mixing different issues here: your own driver design and known
current limitations in net stack.
I will address your driver design issue in your patches (however apply
first style comments).

Currently, all net interface are up and running as soon as they are
initialized. This was done like that because it was just easier to move
on with more important things.
Work is being done to modify this behavior (up/down iface state,
etc...). Drivers will always be initialized before the network stack,
there is currently no design that require
the other way round, even yours.

1. Modern Ethernet modules in most of the SoC devices have ability to
generate IP, TCP and UDP checksums in hardware. Is it possible to
tell networking stack not to compute these checksums in software?
For now, no. There is no generic CRC API that could - depending on
configuration and hardware - either call a software routine or run it on
hardware directly.

1. One of the parameters to NET_DEVICE_INIT is MTU. Shouldn't we have
a set of predefined constants provided by the networking stack for
some typical interfaces. E.g. NET_MTU_ETHERNET set to 1500? Should
we configure the MTU value in Kconfig?
Don't bother with that. MTU is not taken into account in network stack,
this is a big known crappy limitations.
There is on-going work to fix it properly.



Join to automatically receive all group messages.