Scaling to multiple clients

[podhrmic]

Hi @lucypa ! Very exciting work!
I have a question about the client multiplexing mentioned in your presentation - see below:

Do you suggest having multiple IP stacks as shown in the picture? I am thinking about a use case where we have multiple client components that require network access. If the target board has only one NIC, presumably these clients would need to communicate with a single IP stack component (maybe via some sort of socket-like API). Or did you have a different application in mind?

How would this architecture scale to other peripherals, such as I2C, SPI, ...?

[wom-bat]

Yes, we're currently using one library IP stack per client, and multiplexing on MAC address.
A more complicated setup might use a single client that performs DHCP/ARP, and a stateful-packet-inspecting MUX that can distribute based on protocol+port. That makes the MUX more complex, and harder to analyse, so we're not doing it at the moment.

[podhrmic]

@wom-bat I was under the impression that Ethernet PHY typically can have only one MAC address, at least for embedded devices. Do you happen to have an example of a platform that can have multiple MAC addresses on one interface?

In terms of analysis of the MUX - are you thinking about some sort of formal verification of the component?

[Indanz]

I was under the impression that Ethernet PHY typically can have only one MAC address, at least for embedded devices.

That is only true for automatic MAC filtering and insertion for unicast packets, which can be disabled. But to support multicast, it's usually possible to program multiple MAC addresses in a static MAC table, and those can be used for unicast too.