Yes, server and client can use same object, and that is what happens with the current patch when the "mem" handle is the same.

@kib : How can two different processes share a piece of memory if not using the same VM object?

In D11392#257497, @kib wrote:

In D11392#257488, @hselasky wrote:

@kib

There is one more requirement. If I create a swap object I need to be able to offset inside the swap object. Is that supported?

Does the vm_ooffset_t *offset argument in the d_mmap_single() signature does what you need (I am not sure what and why you need) ?

There is one more requirement. If I create a swap object I need to be able to offset inside the swap object. Is that supported?

What callbacks ? If you unref the allocated vm objects on cuse.ko unload, VM will correctly free both objects and objects page queues when the last process unmaps it. For OBJT_SWAP you do not need to do anything else except releasing _your_ references.

If the shared communication memory is still mapped when cuse.ko is unloaded, what should happen ? I do not think that it is really possible to track such situations and prevent cuse.ko unload without huge and really unneeded efforts. Leaving the deallocation of the objects to normal VM lifecycle rules avoids unnecessary troubles, IMO.

Set correct size of allocated VM object in case there is an offset within the object requested by the mmap().

Fix some bugs found during testing.

Looks good to me.

Rework patch based on input.

Thank you. Currently reviewing this patch in Mellanox.

Can everyone have a look at this patch again and press accept ? I want to push this patch unless there are any major blockers.

Instead of using tags have you considered a modified if_transmit that returns the current occupancy-level of the tx queue (as a percentage or some normalized representation)? That would make it fully stateless and we wouldn't have to involve any inp in any of this. Any feature hooked up to inp will work only for IP connections that terminate on that node and not, say, packet forwarding use cases.

Can you add a port option to set DEBUG_FLAGS="-g" ??

Looks good.

The LinuxKPI bits look good to me. Please address John Baldwins comments before committing.

This patch looks good to me. @gallatin do you want to test it aswell before it reaches -head? I'll give it a spin tomorrow.

I'll have a closer look at this tomorrow. Thank you!

@oleg : Beware of the callout return value differences between FreeBSD 9-10-11 and 12 !
@glebius

Looks good. Try to make the commit message a bit clearer: