software design for Ethernet switch

Hello

consider a 24-port layer-2 workgroup level switch, aimed to perform quite
typical tasks, except pure frames forwarding: IGMP snooping, spanning-tree
(STP, MSTP etc.), ARP, may be LACP. Typically such devices have specialized
ASIC doing the most dirty job in hardware, also able to classify traffic and
forward it on the CPU, where a piece of software does with that traffic
whatever it wants.

It was quite a long introduction. Now the question is - are there any
common, idiomatic, approaches to design a software for such environment? For
example, is it always fine to implement protocols on kernel level, and
provide only some handles to a user to tweak protocols settings (the main
disadvantage I see is difficulty to debug and it also requires very deep
knowledge of kernel);

or

it is rather easier, more flexible to leave in kernel space only API
reading/writing the ASICs registers, tables and buffer memory and expose
these routines to the user space via I/O controls or the like. And then we
can implement all the networking protocols in user level (easier to debug,
test etc.)

I would be glad to hear for your opinions and suggestions.

--
Mark

"Mark" <(E-Mail Removed)> writes:
> consider a 24-port layer-2 workgroup level switch, aimed to perform
> quite typical tasks, except pure frames forwarding: IGMP snooping,
> spanning-tree (STP, MSTP etc.), ARP, may be LACP. Typically such
> devices have specialized ASIC doing the most dirty job in hardware,
> also able to classify traffic and forward it on the CPU, where a piece
> of software does with that traffic whatever it wants.
>
> It was quite a long introduction. Now the question is - are there any
> common, idiomatic, approaches to design a software for such
> environment? For example, is it always fine to implement protocols on
> kernel level, and provide only some handles to a user to tweak
> protocols settings (the main disadvantage I see is difficulty to debug
> and it also requires very deep knowledge of kernel);
>
> or
>
> it is rather easier, more flexible to leave in kernel space only API
> reading/writing the ASICs registers, tables and buffer memory and
> expose these routines to the user space via I/O controls or the
> like. And then we can implement all the networking protocols in user
> level (easier to debug, test etc.)
>
> I would be glad to hear for your opinions and suggestions.

My opinion on this is that 'userspace' is (among other things)
intended to be a safe playground for less-than-competent application
developers and this mixes very badly with 'direct hardware access'.