XDP-Newbies Archive mirror
 help / color / mirror / Atom feed
From: "Fingerhut, John Andy" <john.andy.fingerhut@intel.com>
To: Pedro Tammela <pctammela@gmail.com>
Cc: "xdp-newbies@vger.kernel.org" <xdp-newbies@vger.kernel.org>
Subject: RE: Instructions to enable spin locks?
Date: Wed, 4 Aug 2021 16:36:28 +0000	[thread overview]
Message-ID: <MN2PR11MB41736042C46731CF18C809FAA6F19@MN2PR11MB4173.namprd11.prod.outlook.com> (raw)
In-Reply-To: <CAKY_9u3150wk7uywpfHThXe0Zn-8Edp0T_VVC-tD7uO_RLGY2g@mail.gmail.com>

> https://github.com/intel/host-int
>
> In particular, we should use spin locks at least for this map in the 
> program intmd_xdp_ksink.c: 
> https://github.com/intel/host-int/blob/main/src/xdp/intmd_xdp_ksink.c#
> L27-L31

> If I may, I would suggest using percpu hash maps and aggregating the
> stats from the same flow_key in your userspace daemon.  That way you
> can avoid spinlocks completely as it models one key to n values, where
> n is the number of CPUs.  You can even leverage batching if your map
> has a considerable amount of keys[1], which in my experience can
> handle large maps without noticeable overhead.
> 
> Pedro
> 
> [1] https://elixir.bootlin.com/linux/latest/source/tools/testing/selftests/bpf/map_tests/htab_map_batch_ops.c

Thanks for the suggestion, Pedro.

For the EBPF programs I have in mind, they are doing things like
inserting a per-application-flow sequence number into new headers in
each packet in a source host, and then maintaining state in the
receiver hosts for packets that have those sequence numbers added, to
detect whether there are packet drops in the network, i.e. some
sequence numbers are never received.

I know that per-cpu maps exist in EBPF, and they are perfect
when all you want to do is to maintain things like packet or byte
counters, or counters for some other events, because the per-cpu
entries can be combined by adding their counts together.

However, for our use case, I do not see any effective way to make use
of per-cpu maps, and still perform our desired packet processing
functions.  Hence the desire for using spin locks.

Thanks,
Andy Fingerhut

      reply	other threads:[~2021-08-04 16:36 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-04  0:43 Instructions to enable spin locks? Fingerhut, John Andy
2021-08-04 15:33 ` Pedro Tammela
2021-08-04 16:36   ` Fingerhut, John Andy [this message]

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=MN2PR11MB41736042C46731CF18C809FAA6F19@MN2PR11MB4173.namprd11.prod.outlook.com \
    --to=john.andy.fingerhut@intel.com \
    --cc=pctammela@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).