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

Lwa352 ibv #1

Merged
merged 9 commits into from
Jul 7, 2020
Merged

Lwa352 ibv #1

merged 9 commits into from
Jul 7, 2020

Conversation

jack-h
Copy link

@jack-h jack-h commented Jul 7, 2020

Add IBVerbs support

JackH added 9 commits June 30, 2020 19:25
Move IB verbs receiving class to a dedicated C file. When
using the hashpipe_ibverbs library within packet_capture.hpp
directly something in that file messes up the compatibility
of the ibverbs structs (their sizes are different) to those
interpretted by hashpipe. Odd, but working around for now.
Evidently, this is the trigger to make `like_bmon` work
its magic
Increase RX packet depth of IB verbs interface to 32k (this
seems to be the maximum).

Make packet handler use AVX stream store instructions.

1. The receiver is currently hard coded for 64 pols per packet.
   It would be trivial to parameterize this, but it may have some
   small performance implication.
2. Code loads 64-bit values into a 256-bit AVX register before writing
   to memory. If the IBV interface can be tweaked to enforce alignment
   (talk to DM about this) the first stage won't be necessary.
3. 64 pols per packet = 512 bits per memory write (1 freq channel of data).
   Newer machines supporting AVX512 could probably run faster than the current
   code by using _mm512_stream_si512 in place of _mm256_stream_si256
The behaviour of the traceback library has changed in py3, so remove
the now nonexistent call.

Tweak error handling to properly pass an exception to the cleanup print

Fix missing decode()
Time metrics for processing / waiting for input/output
data are helpful for figuringout the bottlenecks in the
pipeline, but aren't particularly intuitive (IMO)
measures of whether things are "fast enough"
This is a gross thing to hardcode, so FIXME.
But, having new sequences periodically means that the header
timestamps can be used as actual timestamps, rather
than just counting bytes in some infinite data stream (which
doesn't seem like a good idea when the input stream is from a
network, and could conceivably behave strangely).

Having timestamps derived from actual packet headers periodically
seems sensible(?)
@realtimeradio realtimeradio merged commit dfdfef8 into lwa352 Jul 7, 2020
@realtimeradio realtimeradio deleted the lwa352-ibv branch July 7, 2020 09:24
realtimeradio pushed a commit that referenced this pull request Jun 22, 2021
merge Makefile from docker-gpu-update
jaycedowell added a commit that referenced this pull request Jun 1, 2023
Updates on high-level API
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants