Re: [Bridge] New Custom Protocol on Ethernet Layer

[Stephen Hemminger <shemminger@vyatta.com>]

On Fri, 30 May 2008 06:32:41 -0700 (PDT)
Zoran s <s_zoran@yahoo.com> wrote:

> Hi everyone,
> 
> I need a help. I started recently investigating
> ethernet layer. I have specific problem to solve. I'll
> try to describe this problem, so you can see what is
> all about. I do not know if this problem belongs to
> bridging, certainly by its definition it is close to
> it.
> 
> I have some ideas how to do this. But I would
> appreciate any thought you might have, any direction.
> 
> The problem: there are number of workstations (up to
> 200) connected by LAN - ethernet, and they all are
> running an application which is in need of real-time
> updates. Within every timer tick defined (2
> miliseconds) every workstation needs to communicate
> certain data (broadcast) so all others can take these
> data, compute data via algorithm and store such data
> in their own proprietary database. The round time is
> the same time (all 200 stations need to communicate
> their data in this time frame).
> 
> One of the solutions to the problem will be to write
> specific application in user space (choose some spare
> ports, make UDP datagram and send it over as IP
> broadcast). But I am affraid the turnaround time might
> change from 2 miliseconds to 0.5 miliseconds, even
> less. Then the Real Time processing could become an
> issue.
> 
> Instead using user space, I think the better way to
> handle this problem is to keep data inside the
> ethernet layer itself. Saying this, the solution to
> this problem will be to create specific customised
> vendor destination address which will act similar to
> broadcast (well known all ones) mechanismus, so each
> workstation receiving this packet will be delivering
> data to the specific for this case database cash,
> embedded in ethernet layer, same way ARP works. The
> application can access the data through driver
> mechanismus (bypassing higher layers of IP protocol
> stack), specificaly written for this case.

You don't need to do it in kernel to get real time performance.
You do need to have all nodes using something like the Linux-rt
kernel (http://rt.wiki.kernel.org/index.php/Main_Page) and use
appropriate QoS (see IP_TOS), and make sure all your infrastructure
is capable.

> I start looking and exploring /net/core/dev.c, but I
> don't see ARP entry code in there. Could anybody,
> please, give me an advice where to look for ARP
> resolution so I can explore further implementation
> changes inside the kernel protocol stack (I need to
> add entry which will do similar things).

ARP is handled by the dst (route cache), not a recommended
place.

> The reason I sent this @ is that I think the bridging
> implementation is in the same set of files (very close
> to ARP), as a different option, so somebody might know
> where to fit the entry for the idea I just described.

No bridging is handled by br_hook.

> If there are misconceptions in my @ I appologise for
> my ignorance related to this matter.
> 
> Best Regards,
> Zoran
> 
> 
> 
>       
> _______________________________________________
> Bridge mailing list
> Bridge@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/bridge