Conversation
|
@mattklein123 @goaway I am figuring out how to test this reliably on CI. I think using the loopback interface and address might be the best route. Will update ASAP. I mainly wanted to get out quick so @goaway could comment on if this is the direction he wanted this piece of work to go on. |
Signed-off-by: Jose Nino <jnino@lyft.com>
|
@goaway @mattklein123 this is ready for review! |
mattklein123
left a comment
There was a problem hiding this comment.
Thanks LGTM. Not sure if you want to merge the other PR first or fix up that PR based on this one?
|
|
||
| absl::optional<std::string> IoSocketHandleImpl::interfaceName() { | ||
| absl::optional<std::string> selected_interface_name{}; | ||
| #ifdef SUPPORTS_GETIFADDRS |
There was a problem hiding this comment.
Will this change based on the other other PR?
There was a problem hiding this comment.
Yep. This will change to use the other PR (#18513) and prevent the ifdefs and direct syscalls.
There was a problem hiding this comment.
The windows failure can also be solved with ^.
| EXPECT_FALSE(maybe_interface_name.has_value()); | ||
| } | ||
|
|
||
| TEST(IoSocketHandleImpl, InterfaceNameForLoopbackExplicitV6) { |
There was a problem hiding this comment.
The test below was not showing coverage for v6. Testing here explicitly.
|
/retest |
|
Retrying Azure Pipelines: |
Signed-off-by: Jose Nino <jnino@lyft.com>
Signed-off-by: Jose Nino <jnino@lyft.com>
Signed-off-by: Jose Nino <jnino@lyft.com>
Signed-off-by: Jose Nino <jnino@lyft.com>
Signed-off-by: Jose Nino <jnino@lyft.com>
|
|
||
| Api::SysCallIntResult shutdown(int how) override; | ||
| absl::optional<std::chrono::milliseconds> lastRoundTripTime() override { return absl::nullopt; } | ||
| absl::optional<std::string> interfaceName() override { return absl::nullopt; } |
There was a problem hiding this comment.
@florincoras @rojkov I believe the same implementation that I wrote (above) for the IoSocketHandleImpl would work here. Do you think it would be worth it to move the implementation to the virtual class? Given that the implementation is based on localAddress() and the os syscalls available it doesn't seem like it would necessarily need to be outside of the virtual class.
There was a problem hiding this comment.
The virtual class is supposed to be just an interface enforcing concrete implementations at compile-time like this trivial stub. Otherwise there's a chance of calling a suboptimal implementation (which e.g. checks os syscall availability first). And in this particular case it could be even an error if something called a user space handle's interfaceName().
But I agree the implementation should be shared somehow where it makes sense. In #19082 I'll need the same code. Even more to that - I need the same implementation for localAddress() and peerAddress(). Maybe utility functions would suffice?
There was a problem hiding this comment.
Agreed with @rojkov. It won't also work for vcl because the interfaces are in another user space process (vpp), so not available via syscalls.
The idea might not be too bright but one could argue that there should've been a syscall to get a socket's localAddress(), peerAddress() and the interfaceName for a localAddress(), so one option would be to add these utility functions to syscall interfaces. The downside however is that we'll pollute those with non-posix apis.
There was a problem hiding this comment.
@rojkov @florincoras thanks for your thoughtful responses. It makes sense to me. I also realize how little experience I have of this line of work. If you dont think that the current addition to the interface is egregious, do you all mind if I implement here as is and let you all handle this when/if you tackle moving localAddress() and peerAddress around?
There was a problem hiding this comment.
I don't, I'm fine with it as it is for now.
|
Overall this looks good from an EM perspective. Left one nit comment. Thanks @junr03! |
|
@rojkov do you mind doing a pass on this? |
|
/retest |
|
Retrying Azure Pipelines: |
rojkov
left a comment
There was a problem hiding this comment.
This looks good! I added a couple of questions to clarify.
Was reading through envoyproxy#18531 and seeing the socket address being looked up for each interface confused me a bit, so let's do it only once. Signed-off-by: Raul Gutierrez Segales <rgs@pinterest.com>
Commit Message: IoHandle - add interfaceName() method. Additional Description: returns the interface name for the underlying socket if the implementation and OS allows. This is done by matching the sockets local address to the address of interfaces as returned by getifaddrs. Risk Level: low Testing: pending UT Signed-off-by: Jose Nino <jnino@lyft.com> Signed-off-by: Josh Perry <josh.perry@mx.com>
Commit Message: IoHandle - add interfaceName() method.
Additional Description: returns the interface name for the underlying socket if the implementation and OS allows. This is done by matching the sockets local address to the address of interfaces as returned by getifaddrs.
Risk Level: low
Testing: pending UT
Signed-off-by: Jose Nino jnino@lyft.com