Listener streams

[nilsalon100]

Implement listener streams

[xtor]

Thanks for the submission! This is a really must-have for the listeners 😊 Let me come back later with some ideas about the implementation and interface.

[xtor]

Some implementation ideas below :) @Lwnzhn was also looking into it.

Starting with the interface, from the ipc.proto point of view, we would need to add something like this as a bare minimum:

message StreamListenerQosRequest {
    string interface = 1;
    string dmac = 2;
    uint32 vid = 3;
    uint32 pcp = 4;
}

And the response:

message StreamListenerQosResponse {
    bool    ok = 1;
    string  vlan_interface = 2;
    uint32  socket_priority = 3;
}

In terms of the internal changes, the Read The Docs detd documentation contains an overview of the local configuration flow for TSN talkers:

For listeners, we would have something similar, but need to deal with:

• Device tuning
• Subscription to the stream DMAC
• Rx optimization (e.g. steer to a given queue)
• VLAN mapping for Rx

We could leave the Rx optimization to a second step.

This would give an idea of the call sequence (Proxy and Service not included):

Manager.add_listener
               InterfaceManager.add_listener
                              SystemConfigurator.setup_listener
                                             DeviceConfigurator.setup_listener
                                                            Ethtool.set_features_ingress
                                                            Ip.subscribe_multicast
                                             VlanConfigurator.setup_listener
                                                            Ip.set_vlan_ingress

For consistency, we would need to rename also some methods, e.g. to have setup_talker and setup_listener as differentiated ones.

Device tuning would be executing the configuration in the Rx side: ethtool --features eth0 rxvlan off hw-tc-offload on Subscription to the DMAC may be using the iproute2 ip call: ip maddr add <STREAM_DMAC> eth0 The VLAN mapping on Rx should do something similar to this, e.g. for VLAN ID 3 and VLAN PCP matching socket prios in a 1:1 fashion:

        ip link add
        link     eth0
        name     eth0.3
        type     vlan
        protocol 802.1Q
        id       3
        ingress   0:0 1:1 2:2 3:3 4:4 5:5 6:7 7:7

The above may need to deal with cases where the VLAN interface was already created, etc. This may be an opportunity to split the ip link add commands for ingress and egress into vlan configuration and egress/ingress mapping configuration. Right now we use a single command, but it is recommended not to do it like this because of potential inconsistencies (IIRC in iproute2 man page).

An implementation strategy could be to:

1. Rename all the “setup” to “setup_talker” and make sure everything is still in place again 😊 Get familiar with executing a simple Python script to test this case.
2. Start with the changes in the ipc.proto, Service and Proxy. Create a simple Python test for it, that simply logs the message on Service side.
3. Then move into Manager and InterfaceManager, and use an incremental approach to implement add_listener on InterfaceManager. Split the changes in different incremental steps. E.g. first device tuning, then add subscription, etc. Modify SystemConfigurator, Ip, Ethtool, etc, and add unit tests as needed.
4. In principle, you do not need to deal with the schedule or basetime for listeners. Other stages may be similar.

@nilsalon100 what do you think?

[nilsalon100]

I think it looks like a great strategy. This clears things up a lot. Thank you!

[xtor]

Initial listeners streams implementation to merge: https://github.com/Avnu/detd/compare/master...nilsalon100:detd:master