From: Tom Talpey <tom@talpey.com>
To: David Howells <dhowells@redhat.com>
Cc: Steve French <sfrench@samba.org>,
Stefan Metzmacher <metze@samba.org>,
Paulo Alcantara <pc@manguebit.com>,
Matthew Wilcox <willy@infradead.org>,
linux-cifs@vger.kernel.org
Subject: Re: cifs RDMA restrictions
Date: Tue, 1 Apr 2025 14:02:28 -0400 [thread overview]
Message-ID: <78c910b0-3391-484e-aa44-42e2f9ff4637@talpey.com> (raw)
In-Reply-To: <563557.1743526559@warthog.procyon.org.uk>
On 4/1/2025 12:55 PM, David Howells wrote:
> Hi Tom,
>
> I'm looking at cleaning up the "struct page" instances in smbdirect.c as much
> as possible. Can you tell me what are the restrictions on the size of a
> segment attached to an SGE? For instance, by:
I started typing a long answer but I ended up not sure of the question.
A single sge is just a hunk of memory that is registered with the RDMA
provider. The routine you're quoting is generating the dma_addr that
the provider (adapter) will use to access the data so it's passing what
the ib_dma stuff wants.
The sge *list* is more interesting. The first sge can have a non-zero
offset but anything that follows it can't. Such a "hole" would require
a subsequent registration, yielding handle(s) that might need multiple
RDMA operations. But it's the caller of the routine you quoted that
figured this out.
I'm going to be testing at SambaXP next week, by the way. If you have
some code, let me know.
Tom.
> static bool smb_set_sge(struct smb_extract_to_rdma *rdma,
> struct page *lowest_page, size_t off, size_t len)
> {
> struct ib_sge *sge = &rdma->sge[rdma->nr_sge];
> u64 addr;
>
> addr = ib_dma_map_page(rdma->device, lowest_page,
> off, len, rdma->direction);
> if (ib_dma_mapping_error(rdma->device, addr))
> return false;
>
> sge->addr = addr;
> sge->length = len;
> sge->lkey = rdma->local_dma_lkey;
> rdma->nr_sge++;
> return true;
> }
>
> Thanks,
> David
>
>
next prev parent reply other threads:[~2025-04-01 18:02 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-01 16:55 cifs RDMA restrictions David Howells
2025-04-01 18:02 ` Tom Talpey [this message]
2025-04-01 19:34 ` David Howells
2025-04-02 17:02 ` Tom Talpey
2025-04-02 17:09 ` David Howells
[not found] ` <CAH2r5ms2J06tJr4VEVDgmcj_1uqOnhYzbC1ybrMWDm=f8wVDoA@mail.gmail.com>
2025-04-02 18:04 ` Tom Talpey
2025-04-02 19:26 ` David Howells
2025-04-02 19:36 ` Tom Talpey
2025-04-02 19:54 ` [RFC PATCH] cifs: Collapse smbd_recv_*() into smbd_recv() and just use copy_to_iter() David Howells
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=78c910b0-3391-484e-aa44-42e2f9ff4637@talpey.com \
--to=tom@talpey.com \
--cc=dhowells@redhat.com \
--cc=linux-cifs@vger.kernel.org \
--cc=metze@samba.org \
--cc=pc@manguebit.com \
--cc=sfrench@samba.org \
--cc=willy@infradead.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