Skip to content

Conversation

@k0ekk0ek
Copy link
Contributor

@k0ekk0ek k0ekk0ek commented Oct 6, 2023

Add support for the LOC RR defined in RF1876. Still needs some basic tests to verify logic.

@lemire
Copy link
Collaborator

lemire commented Oct 7, 2023

Any chance that this can be vectorized for better perf?

@k0ekk0ek
Copy link
Contributor Author

k0ekk0ek commented Oct 8, 2023

Maybe, but it'd be complex because it contains a lot of optional fields (e.g. minutes + seconds in latitude and longitude), so there's always going to be a lot branches? The LOC RRTYPE afaik also isn't used much(?) So, it might be a fun experiment, but it'll probably only benefit really specific use cases(?) If you're just looking for any fun experiment, there's other data types that benefit from vectorization more. e.g. ipv6 or eui48/eui64 (MAC addresses). Those data types are more straightforward and probably more interesting in general (though EUIxx isn't used much in DNS either, but the address format is used in other places too)?

@lemire
Copy link
Collaborator

lemire commented Oct 8, 2023

Ok. I will look at ipv6.

@k0ekk0ek k0ekk0ek marked this pull request as ready for review October 16, 2023 11:26
@k0ekk0ek k0ekk0ek merged commit cd61ea0 into NLnetLabs:main Oct 16, 2023
@k0ekk0ek k0ekk0ek deleted the loc-rr branch October 18, 2023 16:02
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.

2 participants