next: Changes queued for 2017.11 release #1250
Conversation
Initialisation of the shm frame needs to be done in the constructor method to avoid being overwritten by the frame created in core.app. Add a copy of the mtu to the device-specific stats table, add a counter to record the speed of the interface.
Avoid using index sets and just query the registers since it's hard to share this state among the apps. Also do the MAC registration in the right place.
RSS is always enabled, so there shouldn't be a case in which this is a no-op anyway. Also the check is complicated by the fact that RSS can be enabled in many ways (with DCB, VMDq, etc.).
Also add code to unset MAC on stop()
This code is mostly copied from the intel10g.lua driver. Also add a new VLAN test and adjust old tests as needed.
The previous iteration was unreliable for unknown reasons. This refactoring should be clearer and run more reliably.
Also add new test for VLAN stripping
* PFVFTE to enable Tx from appropriate VFs * RTTD1TC for bandwidth allocation algorithm for Tx
The former wasn't updated for an API change and the latter was missing a module declaration.
The tag insertion part of this test didn't work because the MAC didn't match when the app tried to resend the packet. It's not necessary since the transmit test covers this anyway.
Use intel_mp driver instead of intel10g driver
|
Huzzah! The new Great hacking to all the many |
`mode` was not passed to `io.open`.
Set mask.size equals to MAX_NUMNODES if lower
|
Sorry about the wait. I wanted to recommend this for release now but I see a performance regression that needs to be resolved. I will first check if this is related to overuse of trace barriers in #1242. |
|
Confirmed that the performance regression is due to the JIT barrier. The lukego-optimize performance with that change reverted matched master again. I will test using fewer barriers (on entry or exit to an app, but not both) and see if that is better. Otherwise the JIT barrier might not be suitable (too expensive) for app/engine transitions. |
|
I have reverted the calls to So the Let's wait for the standard Hydra tests to complete now and then we should be 👍 for the release. |
|
@eugeneia There is a performance regression on the iperf benchmark but I propose that we ship this now anyway. I have been combing through recent CI results with @wingo on Slack and it seems like the problem is caused by voodoo. I have another branch with almost identical contents that does not show the issue. The only difference is whether the I am reluctant to make a "nonsense" change to "solve" this problem. I would prefer to accept it for now and focus on finding the root cause of why we see variance in the iperf benchmark. I see the new RaptorJIT tooling as the way to do this and so I want to spend my time now on integrating that with Snabb. Hence my willingness to accept this symptom of the root problem (wider variance on the iperf benchmark) for the moment. Hypothetically if the problem is something obscure, like whether two Lua loop bytecode addresses hash into the same JIT hot counter, then there are probably very many different ways that it could be provoked (e.g. choice of C compiler version) and so I am not really confident that nailing down one such issue in the test environment would translate into a real world benefit. This would need to be solved more thoroughly in the JIT after seeing exactly what is really going on. WDYT? |
|
Totally agree. I think #1244 is not included in this release, or is it? Maybe, as a last resort I would test to see if it resolves this regression like it did mine. This doesn’t block the release from my point of view though. Ready when you are! |
|
@eugeneia Glad to hear that this change has helped you. I pushed it here and let's see what Hydra says tomorrow. |
|
@eugeneia This was worth a try but the new benchmark results show the same issue: https://hydra.snabb.co/build/2822290/download/2/report.html#iperf. |
|
In a way that's good to know that the results are the same. I was unsure whether to blame a voodoo change to the software itself or some problem with the statistics! |
7 participants
This release will follow quickly on the heels of the much-delayed v2017.09 release.