RPM #528
RPM #528
Conversation
after netmap sources had migrated to github.
With this feature a user application may allocate its own memory
(e.g., via mmap()) and pass it to netmap while registering (NIOCREGIF)
an interface. If the interface was not already registered, it will pin
the underlying pages in memory and use them for its own netmap_if's,
netmap_ring's and buffers.
Example usage:
void *mem = mmap(...);
/* the user must fill a netmap_pools_info header before passing
* the region to netmap;
* the header is used to split the region into netmap_if's,
* netmap_ring's and buffers
*/
struct netmap_pools_info *pi = mem;
pi->ring_pool_objtotal = 100; /* how many rings */
pi->buf_pool_objtotal = 100000; /* how many buffers */
/* etc. */
struct nmreq req;
/* other nmreq initializations... */
nmreq_pointer_put(&req, mem);
req.nr_cmd = NETMAP_POOLS_CREATE;
fd = open("/dev/netmap");
ioctl(fd, NIOCREGIF, &req);
/* pi is now filled with the actual values used */
Possible uses:
- support of hugepages
- persistent memory (e.g., PASTE)
Bugs:
- while a port is registered in this way, no other application can
open it, not even on non intersecting sets of rings (this may actually
be a feature);
- each netmap_if, netmap_ring and buffer needs to be contiguous in
physical memory; netmap_ring's, in particular, are usually bigger
than 4KiB and netmap may fail to allocate them if the user pages
are scattered around; note, however, that this is not a problem
for the above suggested use-cases;
- nmreq_pointer_put() overwrites nr_arg1, nr_arg2 and nr_arg3; this means
that extra buffers cannot be asked for in the same NIOCREGIF (one may
ask for extra buffers in another NIOCREGIF, possibily on a dummy port)
- Linux only (for now)
Pre-allocated objects that cross non-contiguous pages cannot be used. The previous code skipped these objects may setting their vaddr to NULL in the lut, but this created bugs in the mmap code.
Bitmap initialization is already done during netmap_mem_finalize(), so the action was duplicated.
v11.4 tag before introducing the new extensible control API
- Completed README - Added external kernel sources directories to .gitignore
|
Thanks. |
|
Hmm. I lack experience with squashing and rebase. Maybe you can help me? There are conflicts. Doh. Is this because I merged already tag v11.4 into rpm, and your master is still based on v11.3? How can we sort this out? |
|
This branch looks impossible to recover. I would just create a clean branch starting from the master branch: And the manually copy and git-add the files that you added (maybe taken from your previous branch) |
|
On Aug 16, Vincenzo Maffione wrote:
This branch looks impossible to recover.
I would be, if you merged v11.4 and master.
|
|
Pull requests must be based on master. The 11.4 tag was created only for legacy ptnetmap usage. It's not a stable release. |
Thank you, understood. Is there a forum, newsgroup or mailing list, where I can get the information directly which tags are important or official and which ones are supposed to be "only something"? I will rebase, but would like to avoid the double work in future, of course. I have to finalise a formal request to contribute on your github, with respect to my employer. Then I come back to this. In the meantime, I moved the RPM directory to LINUX (as it is specific to that and it made no sense for me on the same level as WINDOWS). So there will be quite some changes. If you want to keep your tracker clean and close this PR, it is fine for me, and I will open a clean one later this month. |
|
Please ignore all the tags. Some are for specific use (e.g. 11.4 for Feel free to close yourself this PR when you are ready and open another one. Thanks |
|
Please ignore all the tags. Some are for specific use (e.g. 11.4 for ptnetmap), but definitely none is for contributing code.
Yes, but at some point I need to base our distributions on a fixed version.
Ideally we would use the already existing version tags then. Or what would you
recommend?
|
|
This software is rolling release, so there are no releases. |
I am not sure if this is mature enough for merging, but I would like to get into contact with the dev team for discussing.
In our project we need to deploy software as RPM packages. I started to provide the necessary .spec file, and the deployment works well. The necessary files with a README are available in the directory RPM/.
I would certainly like to polish the code a bit more before integrating it into your main repository. And maybe you have some ideas how I should organise my contribution for that. Please advise.
Are you happy with a pull request with all commits, or do I need to squash them into the latest commit first?