Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merge max-next into next for v2019.01 #1404

Merged
merged 54 commits into from
Jan 31, 2019
Merged

Merge max-next into next for v2019.01 #1404

merged 54 commits into from
Jan 31, 2019

Conversation

alexandergall and others added 30 commits June 21, 2018 11:30
Frequent trace aborts due to "register coalescing too complex" have
been observed within handle_fragment().  This commit attempts to
mitigate this by limiting the scope of local variables, either by
explicit scoping with do/end or by placing variable declarations after
function calls that don't need them.
The main processing loop is split into three separate loops to reduce
the effect of unbiased branches due to workloads with either mixed
fragmented/unfragmented packets or a shift from mainly fragmented to
mainly unfragmented packets on the selection of traces.

All packets needing fragmentation are processed in a separate
loop. The fragmentation itself contains another loop which might get
compiled first.  In that case, the pointers passed to
fragment_and_transmit() would require dynamic boxing on the Lua stack,
which cause GC activity.  Explicit boxing is used to avoid this.
The amount of work being done in the main push() loop is reduced by
moving fragments to a separate queue.  This is beneficial if the
workload is unbiased with respect to fragmentation or if the workload
shifts from mainly fragmented to mainly unfragmented packets.

All packets needing reassembly are processed in a separate loop.
Move the logger out of core.lib into lib.logger and add documentation.
Simplify the throttling code by tying it to the logging of discarded
messages.

Update in-tree references to the logger.

Remove the token_bucket:rate() method which was kept for backward
compatibility for the old logger code.
Calibration causes long delays in some selftests that instantiate the
new logger.
The snippets of code that deal with the remaining bytes should be
ifs and not whiles.

For instance, if the remaining bytes to sum are 7, this number is
decomposed as 4 + 2 + 1. For all other numbers lower to 8 their
decomposition is a sum of different values, thus there won't be
iterations.
The change required to support third argument 'initial', return value as
host-byte order value and adapt some selftests.
Found via GCC 8.2's -Werror=stringop-truncation.  NUL termination is
required by the AF_UNIX socket API.
alexandergall and others added 17 commits September 20, 2018 13:41
Add an optional callback which is invoked on an evicted entry to
perform cleanup before the entry is purged from the table.
Make sure that packet.append() is called with a pointer of type
uint8_t *.

The detection of ICMP packets for PMTUD is simplified by only checking
for next_header 58 on the fast path.
Respect the precondition for sort_array().

Use bit.band instead of modulo operator to check for multple of 8 of
the fragment size.
The headers of all fragments are derived from the unfragmentable part
of the original packet, hence the distinction for fragment #0 is not
necessary.
On a call to get_mempolicy, the maxnode argument should
match the size of the given nodemask to avoid buffer overruns.
This commit ensures the size is ok when ljsyscall generates the
nodemask structure.

Cherry-picked from: Igalia#1198
@eugeneia eugeneia requested a review from lukego January 7, 2019 15:05
@eugeneia
Copy link
Member Author

eugeneia commented Jan 9, 2019

  • Need to resolve a conflict with next. I plan to do this by merging next into this branch once next builds.

@lukego
Copy link
Member

lukego commented Jan 16, 2019

Is the problem with next the conflict in .version? I pushed a fix for that now, sorry!

@eugeneia
Copy link
Member Author

@lukego Yep!

Further, there were some trivial conflicts with next I resolved in 91ffca3. If SnabbBot agrees, this should be good to go.

@lukego lukego merged commit c8f5034 into next Jan 31, 2019
lukego added a commit that referenced this pull request Jan 31, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants