Repository navigation
[Question] Error Reporting From Bindings #7
Description
Hi Jeremy,
Today, the AF_MCTP socket will return some errors synchronously (For ex a missing route) as standard errnos. However, once the control is handed over to the underlying netdev and the binding driver, the errors are handled asynchronously and never make it back to the socket FD. From a client's perspective, they would see a recvfrom() timeout, for ex.
I realize that MCTP is by nature lossy, but do you have any thoughts on possible improvements to the binding layers to:
- Propagate the error back via the netdev to the socket layer.
- implement some equivalent of the MSG_ERRQUEUE in combination with a POLLERR on the socket FD to relay asynchronous errors/other debug data back to the client.
Thanks,
Santosh
Activity
jk-ozlabs commentedon Sep 18, 2025
Once the outgoing skbs have been packetised and queued to the device, we don't really have a great mapping back to the originating socket, so the error reporting is somewhat non-trivial here.
It's definitely something I'd like to have implemented, but does need some work to correctly design.
jk-ozlabs commentedon Sep 18, 2025
... and applications would still need to handle errors that occur beyond the driver/hardware boundary anyway, so there's not a huge win for this error reporting.
santoshpuranik commentedon Oct 8, 2025
Sorry, I missed your responses here. Not sure I followed the comment about the applications having to handle errors other than driver/HW. As an application, it is useful to know why my Rx timedout, right? That is, did my Tx fail or did the remote actually never respond. At the moment it is unclear if that alone would be enough to take corrective actions (like try a device reset), but for starters it can be used for reporting for RAS purposes, I think.
The above said, do you think a separate MSG_ERRQUEUE on the AF_MCTP socket to relay these errors back to the client is the right approach (something UDP sockets already do?).
jk-ozlabs commentedon Oct 9, 2025
My point is that there are many error scenarios there:
and that using the socket error queue only provides information about the first; your application still needs to handle the other scenarios too (and any reasonable method of doing so will also cover the first case).
I am not disagreeing with you here - I do think it's worth implementing TX failure notifications through the error queue, just that it doesn't provide much of a benefit to the application, so is fairly low priority.
I have an upcoming change that will help with the error case for fragmented messages, so that may be a bit simpler in future.
santoshpuranik commentedon Oct 10, 2025
Ack. thanks for listing the scenarios out. I understand now what you meant by applications still need to handle other error conditions that cannot reliably be reported in the error message queue.
OK, yes. I think I agree about the priority being low. Just that RAS likes to characterise and report errors even if they do not necessarily provide anything actionable :)