DPDK usage discussions
 help / color / mirror / Atom feed
From: Bruce Merry <bmerry@sarao.ac.za>
To: users@dpdk.org
Subject: Understanding extbufs for transmit
Date: Wed, 2 Mar 2022 11:46:46 +0200
Message-ID: <CAOm-9aoaSTU3LuZ1DAMrxR9a89ivXsXKAsDskbJoSQrfgwwKcw@mail.gmail.com> (raw)


I'm new to DPDK. I'm looking at adding a backend to a high-level
library (https://github.com/ska-sa/spead2) that currently has a
backend using ibverbs raw ethernet QPs for kernel bypass (on mlx5

One of the features of the high-level library is that when
transmitting data, the user can point at arbitrary memory they've
allocated and get zero copy, provided they pre-register memory regions
first. The ibverbs backend maps the pre-registration to ibv_reg_mr,
and when constructing packets it uses a segmented work request with
one segment pointing at headers (in internally-managed memory) and
other segment points at the user-provided memory for the payload.

I'm trying to understand if I'll be able to support the same thing in
DPDK, given that it seems to be geared to allocate memory for packets
from mempools. It looks like mbuf's can be chained to construct a
packet from non-contiguous data, and I see there are some functions
like rte_pktmbuf_attach_extbuf that look promising, but I haven't yet
found any high-level documentation that explains how to use it. For

- What happens to the original memory of the mbuf - is it just wasted
memory? If so, should I be creating a mempool with small mbufs (just
enough to hold packet headers)?
- How do I pin the memory? Is rte_extmem_register the equivalent of
ibv_reg_mr? It's not clear what "registering" memory with DPDK
actually does.
- How should I compute the iova? (in ibverbs, the driver is normally
responsible for dealing with any address mapping)

Bruce Merry
Senior DSP Engineer

             reply	other threads:[~2022-03-02  9:46 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-02  9:46 Bruce Merry [this message]
2022-03-08  8:12 ` Bruce Merry

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAOm-9aoaSTU3LuZ1DAMrxR9a89ivXsXKAsDskbJoSQrfgwwKcw@mail.gmail.com \
    --to=bmerry@sarao.ac.za \
    --cc=users@dpdk.org \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

DPDK usage discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.dpdk.org/users/0 users/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 users users/ http://inbox.dpdk.org/users \
	public-inbox-index users

Example config snippet for mirrors.
Newsgroup available over NNTP:

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git