- User Since
- Mar 10 2018, 1:54 AM (57 w, 5 d)
Tue, Apr 9
Thank you very much!
Mar 19 2019
Feb 18 2019
No worries, and thanks for testing!
Feb 14 2019
In my tests I can see that without the patch, two pkt-gen communicating over a VALE port will consume 9% CPU on kqueue processing (although kqueue is not used), on a separate CPU.
With the patch, the 9% goes away.
Feb 13 2019
We can't. We use a taskqueue there precisely because we cannot take the si->m lock (or we get LOR).
Feb 7 2019
It would probably help to have more lines of contexts for the patch.
If you used git, you should probably use something like:
git diff -U30 [...]
If you used svn
svn diff -x '-U30'
Jan 30 2019
Thanks for testing.
Jan 29 2019
It looks like reading the the HEAD of the first TX ring works, while the other TX rings don't...
knote() notification work deferred to a per-selinfo taskqueue
That's convincing, thanks. I will try to switch to a per-netmap-adapter private taskqueue, to avoid locking contention on the same taskqueue.
Jan 28 2019
Obsoleted by https://reviews.freebsd.org/D18956
I went for reusing a system-wide taskqueue because the work to be done is minimal (i.e. it is not something like processing a number of descriptors in a device queue, or a list of packets, etc.).
However, if you think it's better to use a netmap-wide taskqueue for this, we can go for it.
Are you worried about something in particular, w.r.t. the current approach?
Thanks for testing.
I think this is safe to commit.
Actually some people is experiencing problems when using netmap on ixl (see related PR), so I would like to understand what is going on...
Jan 26 2019
Sanitize the value of the hw head index read at the end of the TX ring.
Jan 25 2019
Thanks for testing. So this seems to work.
However, introducing a global lock is not the best approach for performance reasons. I tried to came up with a different approach that also allows us to get rid of the mtx_owned() call.
Jan 24 2019
I could not reproduce your issue, but this patch may be useful to match the actual locks involved against the corresponding netmap ports.
Thanks for reporting. Also the code sample can be useful to add some unit tests for kqueue.
Jan 23 2019
Uploading diff with some context (-U 100).
Fixed indentation as suggested.
Jan 21 2019
That's another interesting question.
It looks like it was added to support the case where multiple threads poll() on the same netmap port. In that case, one of the thread performs the actual TXSYNC or RXSYNC, and if some work was actually performed (e.g. ring indices were advanced) the thread will call nm_notify() to wake up all the other threads.
Thanks for the explanation. Yes, I understand that this use of f_event is unusual, and I see your point.
Jan 18 2019
Thanks a lot!
Added @markj to possibly answer the question about calling KNOTE() in f_event.
Thanks a lot for testing! Yes, a lot of comments looked really inconsistent with the code. I did some more consistent update.
It would be great if you could run your tests again, since I've done a small code change in netmap_knrw().
Cleanup comments related to kqueue.
Jan 17 2019
Dec 31 2018
Thank you very much for your thorough review!
I will try to convert that to a TAP test, and ask for help if I find obstacles.
Dec 24 2018
Formatted .dist file.
Dec 23 2018
Any more comments? Can I go ahead and commit this?
Dec 21 2018
Thanks for the quick reply!
Dec 19 2018
Make sure av on-stack arrays do not overflow.
In case netmap is not available, you should get something similar
` Executing command: ifconfig create tap7361 up ==> Start of Test #1 [port_info_get] open(/dev/netmap): No such file or directory Executing command: ifconfig destroy tap7361 `
Dec 17 2018
Improve extmem tests.
Dec 16 2018
Addressed more reviewer's comments.
Addressed more reviewer's comments.
Dec 12 2018
Many thanks for the thorough review.
Does it look good enough for commit now?
Thanks a lot for the review! I should have fixed the issue you spotted.
Applied reviewer's suggestions.
Dec 11 2018
Dec 10 2018
Fixed some compilation warnings.
This regression test suite is also run on Linux for continuous integration (see the travis page for more details https://travis-ci.org/netmap-unipi/netmap) and manual tests.
The compatibility with Linux is the the reason why it is a plain C program, so that I don't have two maintain two versions of the same test suite.
Addressed reviewers' comments.
Dec 9 2018
Dec 6 2018
Changes already included in r341477
Dec 5 2018
You're right. I realized that just now.
Import bug fix from upstream.
Dec 2 2018
Add support for nm_config
Forgot to upload updated patch.
Dec 1 2018
Nov 28 2018
Nov 27 2018
The truth is that netmap not setting the IFCAP_NETMAP flag in ifp->if_capabilities after r307394 is a mistake that we did not notice so far.
It got introduced by refactoring, 3 years ago (see https://github.com/luigirizzo/netmap/commit/5d0796f93a1107eb14422c7b8ea416f7fd750a2e).
Sorry for that, it was unintended.
I just happened to notice that and fix it.
Nov 26 2018
Nov 20 2018
Nov 17 2018
Add back $FreeBSD$ strings
Nov 16 2018
Short and sweet but I need to wait for the mentors :)
Nov 14 2018
Nov 13 2018
In any case I plan to import the current github into stable/11 soon, since the current stable/11, to stabilize it.
Nov 12 2018
I'm sorry, but as a design decision for netmap we never automatically change interface features/offloading automatically and restore them.
We require the application or the system administrator to do so explicitely.
In any case this must be discussed with the upstream project https://github.com/luigirizzo/netmap