Skip to content

[202012] dhcrelay: Don't look up the ifindex for the fallback interface (#17797)#18415

Open
yaqiangz wants to merge 1 commit intosonic-net:202012from
yaqiangz:202012_fix_dhcp_relay_delay
Open

[202012] dhcrelay: Don't look up the ifindex for the fallback interface (#17797)#18415
yaqiangz wants to merge 1 commit intosonic-net:202012from
yaqiangz:202012_fix_dhcp_relay_delay

Conversation

@yaqiangz
Copy link
Contributor

Why I did it

Manually backport of this PR: #17797
Currently, whenever isc-dhcp-relay forwards a packet upstream, internally, it will try to send it on a "fallback" interface. My understanding is that this isn't meant to be a real interface, but instead is basically saying to use Linux's regular routing stack to route the packet appropriately (rather than having isc-dhcp-relay specify specifically which interface to use).

The problem is that on systems with a weak CPU, a large number of interfaces, and many upstream servers specified, this can introduce a noticeable delay in packets getting sent. The delay comes from trying to get the ifindex of the fallback interface. In one test case, it got to the point that only 2 packets could be processed per second. Because of this, dhcrelay will easily get backlogged and likely get to a point where packets get dropped in the kernel.

Fix this by adding a check saying if we're using the fallback interface, then don't try to get the ifindex of this interface. We're never going to have an interface named this in SONiC.

Work item tracking
  • Microsoft ADO (number only): 26273071

How I did it

How to verify it

Which release branch to backport (provide reason below if selected)

  • 201811
  • 201911
  • 202006
  • 202012
  • 202106
  • 202111
  • 202205
  • 202211
  • 202305

Tested branch (Please provide the tested image version)

Description for the changelog

Link to config_db schema for YANG module changes

A picture of a cute animal (not mandatory but encouraged)

…-net#17797)

Currently, whenever isc-dhcp-relay forwards a packet upstream,
internally, it will try to send it on a "fallback" interface. My
understanding is that this isn't meant to be a real interface, but
instead is basically saying to use Linux's regular routing stack to
route the packet appropriately (rather than having isc-dhcp-relay
specify specifically which interface to use).

The problem is that on systems with a weak CPU, a large number of
interfaces, and many upstream servers specified, this can introduce a
noticeable delay in packets getting sent. The delay comes from trying to
get the ifindex of the fallback interface. In one test case, it got to
the point that only 2 packets could be processed per second. Because of
this, dhcrelay will easily get backlogged and likely get to a point
where packets get dropped in the kernel.

Fix this by adding a check saying if we're using the fallback interface,
then don't try to get the ifindex of this interface. We're never going
to have an interface named this in SONiC.

Signed-off-by: Saikrishna Arcot <[email protected]>
@yaqiangz
Copy link
Contributor Author

yaqiangz commented Apr 2, 2024

@qiluo-msft Could you help to merge this PR?

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