Advantages of Netmap NM_OPEN_NO_MMAP

[Vincenzo Maffione]

Hi,
  No, each interface open in netmap mode has its own netmap buffers (for
packet data) and netmap rings, independently of what is the netmap memory
region where buffers/rings resides.
Two applications using different interfaces can work independently on each
other (no locks needed), it does not matter whether they are in the same
netmap memory region or not, because the data structures (rings and
buffers) are separated.
It does matter in terms of isolation, of course: two applications using the
same shared memory must trust each other.

Typically you want two interfaces to be in the same netmap memory region
because you want an application to do zerocopy packet forwarding between
the two interfaces.
Also in this case locks are not usually needed, since you would have a
single thread accessing both interfaces. (Or you could have a separate
thread for each TX-RX ring couple, but always without using locks.)

You can imagine a netmap memory region as a pool of buffers and rings,
where one or more interfaces can allocate their buffers/rings when they
enter netmap mode (deallocation is on exit from netmap mode).
Your system can have many memory regions. By default all the physical
interfaces share the same memory region, while each VALE port uses a
private memory region.
This is however being changed to ease arbitrary association between
interfaces and memory regions.

Cheers,
  Vincenzo

2016-11-17 22:50 GMT+01:00 Paras Jha <dreadiscool at gmail.com>:

> Hi all,
>
> I had a quick question about some of the implications of sharing packet
> buffer memory between multiple interfaces. Assuming an arbitrary amount of
> interfaces (> 2) are linked together with NM_OPEN_NO_MMAP and share the
> same memory, would this have any issues with lock contention?
>
> Sorry in advance if this is the wrong place to post, I had seen several
> other archives about Netmap on this mailing list and I thought it was the
> most appropriate place.
>
> Regards
> _______________________________________________
> freebsd-net at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>



-- 
Vincenzo Maffione