Hello,
Is there a priority between a digest_message and packet_in message about how these different messages send from the data plane to the controller?
In my case, i firstly send digest message and immediate after that a packet_in message. in the log file i see that first is sent the digest message and then the packet_in, but in the controller i receive the packet_in message from the stream_message_response queue.
Does anybody know why is this happen?
There is nothing in the definition of the P4 architectures like v1model and PSA that mandates what order digest messages and PacketIn messages arrive at a controller. In general, different implementations might send each of these through two or more different queues in driver software, and it is up to the driver software and perhaps many other factors exactly what order they arrive at the controller.
An implementation should give you some assurances of what relative order different PacketIn messages from the switch to the controller will arrive, e.g. first-in/first-out per class of service, perhaps, but even that is target-dependent and not specified by the architecture definitions today.
Similar for the relative order of different Digest messages generated by the data plane.
Because i want to receive first the digest message in the contorller, can i somehow in the p4 program put the packet_in message to a queue and send first the digest message?
Why not add a custom header to the packet_in messages that contains what you are currently putting into a digest message? Then you can be assured that they will arrive to the controller simultaneously.
This case does not always appear and my program works fine when this case does not appear. If i do such a change i should make a lot of changes in the code, so i try to find an alternative,if it exists.
I am not aware of any way in existing P4-programmable devices to force a digest generated by the data plane to reach the controller before a corresponding packet_in packet generated by the data plane, nor vice versa.
If you can think of a way to make your controller software react correctly regardless of the order that these two things arrive relative to each other, I would recommend thinking about how much work that would be for you.
I would +1 Andy’s suggestion. There is nothing in the P4Runtime spec that guarantees the order in which the stream messages ought to be delivered to the controller. Digest messages are typically generated with information from several dataplane packets (for example a single Digest message will be used to learn multiple MAC addresses), whereas a PacketIn message corresponds to a single dataplane packet.
In the bmv2 + PI implementation, the different message types are processed separately and asynchronously, and they go through completely different queues. Knowing the implementation, it is more likely than the digest message will be sent out first, but there is 0 guarantee,
I think the ability to prioritize messages is fine, but providing ordering guarantees is another thing. I would be wary of a controller implementation that requires reliable delivery of stream messages from the P4Runtime server, let alone one that requires in-order delivery.
So we conclude that the most suitable solution to my problem is what Andy said:
Why not add a custom header to the packet_in messages that contains what you are currently putting into a digest message? Then you can be assured that they will arrive to the controller simultaneously.
For the priority part, it still exists the case that digest message comes second after the packet_in message, right?
But how can i achieve to prioritize messages?
“For the priority part, it still exists the case that digest message comes second after the packet_in message, right?”
As we both wrote above, there is nothing in any implementation that we know about that guarantees that the digest message will become before the PacketIn, nor to guarantee that the PacketIn will come before the digest. If, in your testing, you have consistently seen one arrive at the controller before the other, we believe that is just what you have happened to see occur so far, and if conditions were different somehow, perhaps they might arrive in the other order at the controller. Or maybe it really is guaranteed in the version of BMv2 they will always arrive in that order, but if so, maybe the next version of BMv2 might change that for implementation-specific reasons.
We are both recommending that you DO NOT write controller code that ASSUMES there is a particular relative arrival order of such kinds of messages at the controller. If you do, the system will likely disappoint you at some point in the future, because you made an assumption that was not true.
I want to mention that in different executions i get the correct results so the BMv2 version is not guarantee that.
Thank you guys for your help, i will find a way to fix it.
For my last question, is there a way to prioritize messages?
To prioritize which messages? Prioritize them between which two points of the system?
As priority i mean something like QoS. Is there any reference related to it?
Do you mean you want to have multiple output queues for a single physical output port in the traffic manager, with a packet scheduling algorithm run on those queues to decide which packet is transmitted next, such as a strict priority queue, or weighted fair queueing, etc.?
If so, currently the answer is “it depends upon the target device”. Which target device do you have in mind?
If the BMv2 software switch, there is an option to enable multiple queues per output port, but only if you make a one-line change to the source code and recompile it from source code. Here is an earlier Github issue where this question was asked, and the answer was given for how to change the source code to enable this: Does simple_switch_grpc support priority queue ? · Issue #877 · p4lang/behavioral-model · GitHub
It would be great if someone was willing to enhance BMv2 source code so that multiple queues per port could be enabled with just a command line option, without having to recompile. See here if you are interested in that: Consider making it a command line option to enable priority queues · Issue #1065 · p4lang/behavioral-model · GitHub
If I have completely missed the mark on your question, then I ask you again “prioritize which messages? And prioritize them between which two points of the system?”