-
Notifications
You must be signed in to change notification settings - Fork 17.8k
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
net/netip: IP address bit manipulation functions #49379
Comments
As16 and AddrFrom16 are allocation-free. Also, I plan to make a new package that unifies the inet.af/netaddr and net/netip with the missing pieces. That'll likewise rely on being able to do zero-alloc conversions back and forth. |
allocation-free, but it still copies to the stack, right? Is SSA able to eliminate those somehow? |
Still copies to the stack, but it's super cheap. And I'll send a CL soon that'll make it even cheaper. I think this API is fine. |
API wise, I was hoping some of those uint128 accessors could somehow get exposed, so I could index bits and and, or, and xor limbs together without having to drop down to bytes or roll it all myself. But I could also understand if that's not desirable in general to do. |
I hope we get that via #9455. In the interim, we should copy/paste the uint128 code around as needed. API is impossible to claw back, so for now we should be conservative. |
Change https://golang.org/cl/361674 mentions this issue: |
Alright. Hopefully the compiler can optimize: Addr -> endian converstion -> array -> endian conversion -> myu128 -> arithmetic -> myuint128 -> endian conversion -> array -> endian conversion -> Addr Into Addr -> arithmetic -> Addr That seems like an impressive feat though. |
Let's see how it does. |
This seems like a potentially much larger topic than the "little things" of #49298 so I've made a separate issue for it.
I have a trie data structure that works over
net.IP
with lots of bit twiddling. It works well, but of course I want to switch it over tonetip.Addr
, and benefit from performance there. However, there currently is no way of getting at its internal uint128 guts, or doing any arithmetic therein.Seems like this would be a nice thing to add. I don't have a concrete proposal for how to do this yet (so this isn't a "proposal: " issue), but I thought I should still start the discussion.
CC @bradfitz @crawshaw @josharian @danderson @ianlancetaylor
The text was updated successfully, but these errors were encountered: