[etherlab-dev] EoE patchs and questions

[Esben Haabendal]

Graeme Foot <Graeme.Foot at touchcut.com> writes:

>> -----Original Message-----
>> From: Esben Haabendal [mailto:esbenhaabendal at gmail.com] On Behalf Of Esben Haabendal
>> Sent: Thursday, 1 March 2018 2:02 AM
>> To: Graeme Foot <Graeme.Foot at touchcut.com>
>> Cc: etherlab-dev at etherlab.org
>> Subject: Re: [etherlab-dev] EoE patchs and questions
>> 
>> Hi Graeme
>> 
>> Graeme Foot <Graeme.Foot at touchcut.com> writes:
>> > So the first patch does a few things:
>> >
>> > 1) adds explicit eoe_addif and eoe_delif tool functions so that you
>> >    can manually add/remove an eoe iface without the slave existing
>> > 2) no longer deletes and eoe iface if the slave disappears
>> 
>> This is a behavioral change compared to how eoe interface work now.  And it
>> will break our current system, which relies on the interfaces being created
>> and deleted together with the slaves.
>
> The changes have added a couple of settings to the ethercat config file
> (EOE_INTERFACES and EOE_AUTOCREATE).  The default for EOE_AUTOCREATE is true,
> so eoe interfaces will be autocreated as EOE slaves are connected.  The only
> "breaking" behavioral change here is that they will no longer be deleted when
> the slave is removed.

Yes, I see that.

> The only issue I have with this is that if you connect a slave that
> does not yet have an alias set, it will auto-create using position
> naming (e.g. eoe0s4).

We don't use aliases, but I have other issues with the change.

We have created a daemon which listens to netlink(7) messages, taking
appropriate actions when interfaces come and go, links go up and down.
This is used to setup all network related configurations, including
adding eoe interfaces to bridges.

This will obviously not continue to work as it does if eoe interfaces
suddenly is not deleted when slaves disappear.

> Once the alias is set it will auto-create using the alias naming
> (e.g. eoe0a16000) but keep the position named eoe port.  As this is
> usually at setup and configuration time then you are likely to reboot
> and it will be gone.  (Or you can explicitly call the eoe_delif
> function.)
>
>> 
>> With EtherCAT being a dynamic structure, I don't see this new way is
>> supposed to work in general use-case, where the bus configuration is
>> not guaranteed to be fixed.
>
> When the EOE slave is removed the port transitions to a disconnected state
> (like pulling the plug out of a normal network card).  My (unfounded) feeling
> is that this would be preferable to other software using the port rather than
> deleting the interface all together.

This way of looking at it implies a static EtherCAT bus configuration.
By nature, EtherCAT is dynamic.  Whenever changes are detected, the bus
is rescanned, and slaves are added / deleted accordingly.

When the bus configuration is changed, the new configuration might not
be wrong, so insisting on the previous configuration could therefore be
problematic.

> It also means that if you have added the port to a bridge (my use
> case) then it will remain in the bridge and resume once it is plugged
> back in again.
> If it is deleted then it is removed from the bridge and the next time
> it is plugged in again it will need to be manually re-added it to the
> bridge.

As described above, we handle this in the dynamic case.  If an interface
is deleted, it is naturally removed from the bridge.  If it is added
again, it will added back to the bridge.

> I would think that even in a dynamic structure if an EOE module has
> been plugged in once it is likely to be plugged in again at some
> stage.

Maybe, maybe not.  It really depends on the use-case.

>> Would it be possible to make this new behavior optional, so that the
>> default behavior is as it is now?
>
> Sure.  Two options:
> 1) Have another ethercat config file option: EOE_AUTODELETE (default true)
> 2) Have EOE_AUTOCREATE also mean that it will auto-delete.
>
> I prefer option 2 for ease of implementation, though option 1 would be better
> if my assumptions above are correct.  Try the attached completely untested
> (and manually edited) patch file for option 2.

I think I prefer option 2.  I think it could cause to much trouble to
enable auto-create without auto-delete.

Think for example of a system where slaves have separate power supplies.
When powering up the system, you might have some temporary bus
configurations until all slaves are powered up.  If you have auto-create
and not auto-delete, you will risk having random garbage eoe interfaces
created during that.

>
>> 
>> /Esben
>>
>
> I'm interested to know what your application is to have such a dynamic structure.

Let me answer that in two ways.

1. I really believe EtherCAT is a protocol with an inherent dynamic bus
structure.  While you can specify a desired bus configuration, and try
to do error checking with the scanned bus, the fact is still that bus
structure really is dynamic.

2. Our systems are build on a number of separately powered racks.
Sometimes installed far from each other.  We need to handle power up of
these in any order.  And we need to handle random power cycles of
distributed racks.  And to make matter even "worse", we aim at building
applications that can work with optional features, i.e. optional
EtherCAT slaves might or might not be present.

/Esbem