[newbie] UDS client or API specification?

[thediveo]

I've browsed a little bit through the repo source code and I've seen the internal udsserver and uds packages. The uds package seems to be the part I've marked in the above illustration, taken from the documentation in this repository.

What I don't understand yet and haven't found any explicit documentation or examples (if I'm not mistaken): how do I now use this in my container workload, how do I integrate the UDS client into my own workload code?

[garyloug]

Hi @thediveo The little purple square on the diagram is not a UDS client, it's just representing the actual UDS socket file.

The uds package is just for basic read/write/dial/listen functions. The udsserver imports uds and implements the little server we have for handing over the XSK Map file descriptor to the containerised workload, allowing the workload to go on and create the AF_XDP socket. This handover involves a little "handshake" across the UDS.

I think what you're asking for is a udsclient that you can import into your code and would it perform the "handshake" for you. I'm afraid this does not exist, though it's a really nice idea, I like it.

So, at least for the moment, without such client, your workload has to perform the "handshake" itself. This entire list of calls in the handshake can be found here.

Not all calls are necessary. The main ones are:

• /connect, hostname where hostname is the name of your pod - $HOSTNAME within your pod
• you should hopefully receive a /host_ok response
• then you can request the xsk fd with /xsk_map_fd, dev where dev is the network device you want the FD for. This can be called multiple times for pods with multiple netdevs attached.
• all going well, the device plugin will return a /fd_ack and the XSK FD will be contained in the control buffer part of this message.
• /fin will close the uds connection

You can see some of this implemented in our little end-to-end test here and the CNDP project implement it (in C code) in the uds files here.

KR, Gary

[garyloug]

@patrickog11 @davecremins @maryamtahhan thoughts on the client idea? A package that folks could import into their code and it would do the handshake for them.

[thediveo]

Thanks for the responses!

1. Some devs and projects might need a C binding. Today, there's libxdp. The Go client package could be used as illustration of the API.
2. Is the fd passed to the client really an XSK fd or rather the fd for a map of XSKs? Because otherwise the XSK would need to be created using some undocumented default values for the various rings.

[maryamtahhan]

@garyloug the client package idea makes sense to help out folks that aren't using c based solutions for sure.

@thediveo the fd passed is the fd for the xskmap. The pod owns the whole netdev once it's in the Pod network namespace and there's one xskmap per device. So if it (the pod) needs to create and open multiple af_xdp sockets it's free to do so once it has reference to the map.

[thediveo]

actually, I was looking to the C client to use as I would suspect many people to head for C when dealing with XSKs on the data plane.