From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Edvard Fagerholm <edvard.fagerholm@gmail.com>,
xdp-newbies@vger.kernel.org
Subject: Re: Expiring flows in an XDP based router
Date: Sun, 18 May 2025 18:19:36 +0200 [thread overview]
Message-ID: <87ecwlki1z.fsf@toke.dk> (raw)
In-Reply-To: <CAMF0iZ4tUEsoVj3ZTYwUxEONj-9n61qw4N-Owp_ZQC4Qp3dE1Q@mail.gmail.com>
Edvard Fagerholm <edvard.fagerholm@gmail.com> writes:
> Hi,
>
> I'm working on an in-house router and I'm looking for some advice on
> whether to try to implement some functionality directly in an XDP
> program or instead use AF_XDP sockets with the additional flexibility
> provided by userspace.
>
> We basically have a flow table, which contains entries of the form:
>
> (source ip, source port) -> (action, timestamp)
>
> Every time we see a packet belonging to a flow, the timestamp is
> updated and if the flow has been inactive for e.g. 10 seconds, the
> flow is considered inactive and should be deleted. Actions are of the
> form:
>
> "forward packet to a.b.c.d port X using source port Y"
>
> The challenge that I have is how to clean up expired flows. Built-in
> options would be BPF_MAP_TYPE_LRU_PERCPU_HASH. However, dropping an
> active flow would be unacceptable.
>
> I'm looking at at most 10k new flow entries being added per second per
> router with a maximum number of concurrent flows at around 256k. Each
> flow sends a packet at least every 5 seconds, but most every 50ms.
> Does this allow me to tune the table size in such a way that no active
> flows can be evicted? If not, are there any other reasonable
> approaches for cleaning up the flows?
Well, hard to tell with only the number of additions. I mean, 256.000 +
10.000 * 10 seconds means you'd need on the order of 356k entries in the
map, assuming flows expire at the same rate as they are added. Do you
assume any such guarantee?
Alternatively, you could have your XDP program start a BPF timer and
perform the periodic cleanup from that. There will be some overhead from
walking the map, and a potential for racy behaviour if the same flow is
expired and re-added frequently, but otherwise this should be quite
doable.
In any case, you'd need to size your map so that it doesn't fill up
before flows expire. So whether to use an LRU map is a case of whether
overflowing the map will result in overwriting existing entries, or
blocking the addition of new ones.
-Toke
next prev parent reply other threads:[~2025-05-18 16:19 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-18 14:28 Expiring flows in an XDP based router Edvard Fagerholm
2025-05-18 16:19 ` Toke Høiland-Jørgensen [this message]
2025-05-18 17:11 ` Edvard Fagerholm
2025-05-19 10:10 ` Toke Høiland-Jørgensen
2025-05-29 21:51 ` Vadim Goncharov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ecwlki1z.fsf@toke.dk \
--to=toke@redhat.com \
--cc=edvard.fagerholm@gmail.com \
--cc=xdp-newbies@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.