[Question] Error Reporting From Bindings

[santoshpuranik]

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

[jk-ozlabs]

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]

... 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]

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]

That is, did my Tx fail or did the remote actually never respond.

My point is that there are many error scenarios there:

• that the TX failed - in a way that the MCTP core or the transport driver could detect
• that the TX failed - in a way that was undetected by the transport (say, bus contention)
• packet loss/corruption on the link itself
• that an intermediate bridge failed to receive, route or transmit a packet
• that the remote RX failed
• that the remote processing failed
• that the remote response TX failed
• that the local response RX failed

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]

That is, did my Tx fail or did the remote actually never respond.

My point is that there are many error scenarios there:

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.

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.

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 :)