Ratedsource configurable headroom #4
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Moreover it clash with linux/fs.h definition
Somehow, even with only one queue in RX this field is dangling. Fix tbarbette#359. In ixgbe and i40e that lead to accessing an inexisting queue. Proper support would be to initialize the device with multiple queues, or us multiple ToDevice with a QUEUE argument and use one queue per thread. But that's for another day...
Fix isse with --enable-dpdk-pool because of a dependency loop
A bad merge, probably... This will show clearer the problem when there are not enough queues to serve a TX DPDK device. In this case we must rely on locking, but I don't want to start locking automatically. The user may augment the number of available queues with virtual devices. Should fix tbarbette#71
This patch gives a slight performance boost Signed-off-by: Georgios Katsikas <katsikas.gp@gmail.com>
This patch allows FromDump elements to generate packets from pcap traces while being able to enforce a fixed frame size. This configuration could be handy when you want to use the very same Click code to generate either arbitrary frame sizes from a trace or fixed frame sizes from the same trace. Default behaviour is unchanged. Signed-off-by: Georgios Katsikas <katsikas.gp@gmail.com>
User can select to supress warnings about delayed packets. Default behaviour remains as before Signed-off-by: Georgios Katsikas <katsikas.gp@gmail.com> k
In theory...
This is a temporary solution to the problem so let's keep this pull request open until I commit a better solution to the memory problem Signed-off-by: Georgios Katsikas <katsikas.gp@gmail.com>
This commit closes the pull request on my side. Now the focus shifts to the memory management issue once FromDump has allocated a large enough packet outside of the DPDK zone. Signed-off-by: Georgios Katsikas <katsikas.gp@gmail.com>
The check here appears to be intended to make sure that we only connect if both indexes are valid; specifically, idx can be -1. Unfortunately, it checks (*cp)[0] twice. Instead, check (*cp)[1] too. Thanks, American Fuzzy Lop Change-Id: I5cdeb45ac0cef5bbb0a18c6f19b4540df8007bfe
A malformed IP6Address, i.e. with more than 8 components, will cause the memmove/memset at the end of parsing to fail. This code is supposed to move the post-:: bytes to the end of the address and zero out the bytes in the center. Instead, it moves some of the bytes the wrong way, potentially writing prior to parts[] and then zeroing with a negative size. Instead, make the parser stop when it hits 8 components and let parse figure out that we did not consume the entire String. Thanks: American Fuzzy Lop Change-Id: I2966cb22fb5b44eb9e92dfc6a94e891cf5d02fa7
Let's have a few elementclass that implements what everyone repeats
If parallel, all available threads will open one queue of each device, for better load balancing. If shared (current default and behaviour), threads will be split among devices, for better CPU locality.
Soon to add GRE and ERSPAN, let's not make thousands packages, those are all for some kind of encapsulation
Allows to set various informations in annotations, timestamp if Type 3, ...
Add the split function Correction in trim, by Georgios Katsikas
Correct the get_spawning_threads function CPUSwitch outputs packets oon a given output with only one CPU, of course
The handler allows to query the number of packets left in the queue
Some odd assignment could create a problem there
…Packet::data These two uint16_ts may end up placed at arbitrary offsets into a packet. In order to generate proper unaligned read/write instructions, mark the struct as packed. This was exposed by Defensic suite IPv4 Header Fragment-offset, test 45067 and discovered by Waldin Stone. I verified it by asserting proper alignment of ChunkLinks and found that they were not always properly aligned.
When storing the first of a series of fragments, IPReassembler copies the IP header from the fragment to the reassembly buffer. However, the header of the new fragment may not be the same length as the original fragment that created the buffer. If the new fragment's header is shorter, we will end up with weirdness preceeding the payload. If the new fragment's header is longer, we will overwrite the payload and possibly overrun it. Both cases show up as 'bad mem_used' warnings. Changing header_delta in the p_off=0 case to account for header length changes (and not just offset changes) fixes the issue. Found by Waldin Stone, running Defensics. Signed-off-by: pallas@meraki.com
We actually need to make sure to expand the data area to hold ChunkLink; right now, it's just checking the size of the data, so we might write out of bounds later on. Found-by: jtruba@meraki.com Thanks: AddressSanitizer
Also description update for InfiniteSource
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.