MAC_LEARN_RECEIVER

[lmingcsce]

What does this const value mean exactly and how to decide it?

[antoninbas]

According to the P4 spec, the first parameter of generate_digest is an opaque value which identifies the receiver of the learning notification. In bmv1, this parameter has to be equal to 1024 in order for learning to happen (let's say this is the identifier of the bmv1 learning channel, and that all other receiver values will lead to the generate_digest call being ignored). In bmv2, this first parameter will completely be ignored (you can set it to whatever you want) and all learning notifications go to the same channel (they are broadcast on an IPC socket).

[lmingcsce]

Thanks for you reply. So it means 1024 is the learning channel for bmv1.Will the mac learning can automatically happen or we should write the channel handler via an IPC socket?

[antoninbas]

On bmv1: it depends on whether 1) you write a C application and link it with the bmv1 binary, or 2) do learning through the Thrift RPC server. For 1), the PD library lets you register a callback that will be called every time a new value is learned. For 2) you have to periodically poll the RPC sever to check for new samples learned. I found an old email I sent about this: https://gist.github.com/antoninbas/490676675388c25d6de9 On bmv2: learning notifications are published on a nanomsg IPC socket. There is an example C++ application which does learning checked in the bmv2 repository: https://github.com/p4lang/behavioral-model/blob/master/targets/l2_switch/learn_client/learn_client.cpp I would advise using bmv2, as bmv1 is likely to be be officially deprecated soon. Noe that in both cases, populating the mac tables is the responsibility of the application. The switch generates learning notifications, but it is up to the application to act on them.

[lmingcsce]

I see. Thanks for your reply.

[qin-nz]

@antoninbas How can I implement several applications outside of P4, not just mac learning?