Hi Thomas, On Tue, 31 Mar 2026 at 02:01, Thomas Schwinge <[email protected]> wrote:
> Do we actually need a separate thread in nvptx-tools 'run', with all the > complexity that multithreading brings with it? > I am actually not very sure how nvptx-run has been implemented. But I understand that it runs only a single GPU kernel at a time. I have seen the code, and it appears to me, from a high-level perspective, that we are at first manually setting up the GPU memory and then loading the PTX code. The code run is probably not asynchronous, so when the PTX code is running the main thread gets busy. So I thought maybe we could use a separate RPC thread and use shared pointers. I have to study more about this and I am not fully sure of it, though. I am sure you could help me out with this. A documentation regarding this would certainly be helpful. In fact, I could spend the bonding period trying to understand the code for nvptx-run at first. > You've correctly identified that we, approximately, need one kind of RPC > "message" per POSIX I/O function, and the general structuring of the > "unstructured blob of memory". > Thanks! > For your 'struct RPC_Message', a cleaner approach is possible, that makes > it obvious which data fields are relevant for which kind of 'func_id', > and also maximizes, for example, the 'buf' size usable for > 'ID_READ'/'ID_WRITE': in those two case we don't need the 'path', > 'flags', 'mode' that we need for 'ID_OPEN' -- and vice versa. Which C > language construct(s) could we use? (Which feature of C++ does this > correspond to, roughly?) > We can have struct typedefs for the different function ids. Then we can just typecast RPC_Message based on function ids and pass it as a struct pointer to a given function accepting a struct RPC_Message pointer. I have to see, maybe some other "better" approach is possible, but this is what I can think of at the moment. > What could we do instead of having a separate 'struct RPC_Return' in its > separate shared memory space? I think we could just merge the field of struct RPC_Return in RPC_Message and use a single struct pointer. > > How to make sure that host doesn't already start acting, while the GPU is > still populating the 'struct RPC_Message', and vice versa: how to make > sure that GPU doesn't already resume acting, while the host is still > populating the 'struct RPC_Message'/'struct RPC_Return'? > I think we use atomic operations for that? > I don't follow the motivation for needing a timeout mechanism on the GPU; > I don't think we need that complexity. > Fine. > You've correctly identified that simple synchronous communication is > sufficient for POSIX I/O, for purpuses of this project, and that no > multiple RPCs can be happening, concurrently. Let's assume (to begin > with, at least) that there's only a single GPU thread making RPC > requests. > > How do we (simply) implement things so that a client request to, for > example, write 123456 bytes of data is acted on in some meaningful way > even if we have just a 'char buf[MAX_DATA_BUFFER_SIZE];' of 1 KiB, for > example? Consider POSIX 'write' semantincs. > The POSIX specification says that in cases when the data to be written is larger than the buffer size, write() would just fill the buffer upto its limit and just return the number of bytes successfully written. For C-string compliance, we would write MAX_DATA_BUFFER_SIZE - 1 bytes and keep the last byte for '\0'. The value returned then would be MAX_DATA_BUFFER_SIZE - 1. Whatever bytes are left out could be written in subsequent RPCs. I will try to update my proposal and submit before the deadline. But in case I could not, we could just discuss here about how things should be done. And in case there is an option to update it at any time later, I would surely update it. Regards, Arijit
