OpenAVB (Listener and Talker) demo on LS1021 ?

Hi Raphael,

First of all, please look at OpenAvnu and LS1021A-TSN through the lens that this board is supposed to be the AVB network switch - neither the talker nor the listener. If you want to transform it into a talker/listener, I think you owe further explanation about what you want to stream from it on the talker side, and how you want to present it on the listener side. I think the only multimedia I/O on this board is a SAI interface.

That being said, the rest of the response is going to assume the request was for an AVB switch stack.

I think the main problem of OpenAvnu code is that it, much like the OpenIL board support for the LS1021A-TSN, was built with too narrow focus on a specific set of network interface cards. As such, the two implementations do not speak a common interface between the AVB stack and the platform enablement. That is partly because the kernel interfaces for AVB/TSN had not been put into place at the time those projects began. That is also why your request - port OpenAvnu to the LS1021A-TSN interfaces - is non-trivial to do, and perhaps not even the best use of anybody's time. There have been many discussions in the Linux networking community, and interfaces for AVB/TSN shaping are slowly appearing: tc-taprio, tc-etf, tc-cbs etc. However, the balance is fragile, and spending any more time now on non-standard interfaces risks undoing a lot of the progress that has been done. Personally I have been trying to make steps with the LS1021A-TSN towards a more streamlined application interface. I am maintaining a kernel based on net-next which can be configured with all standard tooling from iproute2. All Ethernet ports, including the 4 switch ports (via the DSA kernel abstraction), are regular net devices and capable of supporting all the normal BSD socket operations (send, receive, timestamping, etc). I expect that the portions of OpenAvnu that were written with a generic interface in mind do actually work just fine on that kernel. I just git cloned the repository and tried to compile it on my box that's running Arch Linux ARM. The "daemons" target compiled just fine and I appear to be able to run mrpd (which does nothing) on a switch port, but then I tried to compile a simple_talker when I noticed in examples/simple_talker/simple_talker.c:

    err = pci_connect(&igb_dev);
    if (err) {
        printf("connect failed (%s) - are you running as root?\n",
               strerror(errno));
        return errno;
    }
    err = igb_init(&igb_dev);
    if (err) {
        printf("init failed (%s) - is the driver really loaded?\n",
               strerror(errno));
        return errno;
    }
    err = igb_dma_malloc_page(&igb_dev, &a_page);
    if (err) {
        printf("malloc failed (%s) - out of memory?\n",
               strerror(errno));
        return errno;
    }
(...)
        err = igb_xmit(&igb_dev, 0, tmp_packet);

I mean I don't even understand what is the level of expectation to run this program on anything other than the igb device whose queues have been exposed to user space. I do see a few calls to:

        igb_set_class_bandwidth
            (&igb_dev, 1, 0,
             sizeof(*l4_headers)+L4_SAMPLES_PER_FRAME*CHANNELS*2, 0);

which is credit-based shaper configuration, and fundamentally I think this is what you want to see demoed. Now even with the kernel based on net-next, the sja1105 driver does not currently support to offload that, although the configuration model is now clear and it is only a matter of time until it will. But there is also a software implementation of tc-cbs which can be evaluated at any time for NICs that are not hardware capable. That is the nice thing about the hardware configuration model of NICs in the kernel: special hardware abilities are only seen as offloads of what the kernel can already do in software. That avoids by design situations like the one at hand - user space code to drive certain hardware. I think trying to integrate OpenAvnu into OpenIL is counter-productive and makes no sense at this point once you understand what they are. OpenIL is a distribution that repackages software for specific boards. There is no reason for it to integrate an application stack for hardware it does not support. And if you patch the application stack to support other, more generic hardware, then putting those patches in OpenIL is the surest way they will die from lack of maintenance. OpenIL by its nature is the absolute last piece in the chain that will get there. It is already slow enough to integrate the hardware support from mainline for the LS1021A-TSN. Otherwise all activity needs to happen on the OpenAvnu front, with questions on the netdev mailing list where the interfaces are not clear or complete enough. I am sure OpenAvnu people are glad to take patches that rework the stack towards a more generic interface, based on Levi Pearson's comments. I am also glad to help with concrete questions on this hardware (where things should work but don't), or with platform-side implementations where necessary. I would suggest you to take a step back and start off with a generic kernel and rootfs for the board which allow you to compile on-target (there are plenty if you look around) and first seeing what it can do with linuxptp and the iproute2 tooling: bridge fdb, bridge vlan, stp_state, tc qdisc, tc filter, etc, and what's missing. Then you can start off by running and testing each application one by one - some will work, some won't - and then fixing the ones you care about. I think you'll find that most of the code just needs to be deleted anyway.

Hope this helps, -Vladimir

nxp-archive / openil

OpenAVB (Listener and Talker) demo on LS1021 ? #24