[etherlab-dev] Userspace fork of Etherlab

[Frank Heckenbach]

Jeroen Van den Keybus wrote:

> The Etherlab developers are
> >   obviously not interested in those changes, so I have to maintain
> >   them myself.
>
> I'm not sure. They are rather in a continuous state of business, I would
> say.

OK, I shouldn't speculate about motivations, but the result to me is
the same.

> - If I had known and considered all this back then, I might have
> >   started with other code instead of Etherlab which is already
> >   userspace based, but has different interfaces (and possibly
> >   different bugs).
>
> It is often instructive to review why you made the initial choice. You
> could be forgetting important positive arguments. For me, that would
> include the fact that Etherlab is a clean, well-structured project which
> has a sizeable user group.

I suppose so (though I never researched the alternatives too closely
-- at the time, RTAI seemed the natural choice and Etherlab was the
only one that supported it). OTOH, considering the amount of time
(several weeks in total) I spent finding, debugging and fixing the
various bugs, I could probably also have gotten one of the
alternatives to a useful state, even if they might not have been so
clean and well-structured.

But all that's academic now. I don't really consider porting my
application to another code base. Porting Etherlab to userspace
seems much easier in comparison: Most of the changes will (almost :)
follow the old saying "if it compiles, ship it", since when
replacing/adjusting kernel functionality, compile errors will show
immediately what's missing; whereas the complex logic (e.g. my
changes WRT mailbox dispatching, but also the master and slave logic
of the original code) will stay mostly untouched.

> > But as things are now, since my code is tightly
> >   bound to the Etherlab interface, and well tested with (the patched
> >   version of) it, it seems easier to port this code to userspace
> >   than change my application code.
> 
> If it get it correctly, you consider porting your code that is running in
> kernel space to user space. I would say that, depending on your platform,
> that conversion is a no-brainer and Etherlab has little to do with that.

No, I actually plan to port the whole of Etherlab to userspace.
That's a little more involved. I think I can handle the interface
differences. The only thing I was really unsure about is packet
latency (which was of course the only reason to use RTAI in the
first place back then).

> > - Use the generic backend driver which also shouldn't require too
> >   many changes since it already uses a raw ethernet socket which is
> >   also available from userspace).
>
> The raw ethernet socket has limited zero-copy capability and not every
> driver is optimized for it.

Do you know which drivers work best with it?

(For a fair comparison, I should note that the non-generic Etherlab
drivers also limit the choice of network adapters. For me, the only
viable choice ATM is e1000; others report rtl8169 works better, but
in my initial tests it didn't; though this might have been due to
the other bugs I found later; after I found and fixed the bugs in
the e1000 driver, it's been working well for me, and I didn't go
back to rtl8169. In any case, the choice of network adapters for
EtherCAT is quite limited, and as long as at least one popular model
is among them, I can live with that.)

> It's great (and designed) for capturing massive
> amounts of traffic (mostly Wireshark), but low latency was never the
> objective. Be warned.

Please correct me if I'm wrong, but isn't zero-copy about
performance rather than latency? Performance is not really an issue
for me (our peak load is well below 1 MByte/s), and a fixed latency
overhead due to copying shouldn't matter much either -- in other
words, I don't care if the CPU is busy dealing with the network
adapter while sending out and receiving packets; it would be idle
during this time otherwise; my application code runs in the time
between.

What worried me more is network packets delayed by other
(non-cyclic, unplanned) activity such as network traffic on another
adapter, disk I/O, etc., but I did some timing tests which look
alright (see my answer to Florian).

> I'm trying to convince you to reconsider your choice to fork, because I
> think that the choice may not be based on the correct arguments, but also
> because Etherlab would benefit from as large a user base as it can get. In
> a sense, it is already a niche project as it is.

This sounds nice in theory, but in practice my experience has been
little different.

What good is a large user base? Right, you get more tests, bug
reports and fixes. But if those get ignored, well ...

Regards,
Frank

-- 
Dipl.-Math. Frank Heckenbach <f.heckenbach at fh-soft.de>
Stubenlohstr. 6, 91052 Erlangen, Germany, +49-9131-21359
Systems Programming, Software Development, IT Consulting