Markus Elfring wrote:
> >> …
> >>> +++ b/include/net/devmem.h
> >>> @@ -0,0 +1,115 @@
> >> …
> >>> +#ifndef _NET_DEVMEM_H
> >>> +#define _NET_DEVMEM_H
> >> …
> >>
> >> I suggest to omit leading underscores from such identifiers.
> >> https://wiki.sei.cmu.edu/confluence/display/c/DCL37-C.+Do+not+dec
On Tue, Nov 7, 2023 at 12:44 PM Stanislav Fomichev wrote:
>
> On 11/06, Willem de Bruijn wrote:
> > > > > > I think my other issue with MSG_SOCK_DEVMEM being on recvmsg is that
> > > > > > it somehow implies that I have an option of passing or not
> > > > I think my other issue with MSG_SOCK_DEVMEM being on recvmsg is that
> > > > it somehow implies that I have an option of passing or not passing it
> > > > for an individual system call.
> > > > If we know that we're going to use dmabuf with the socket, maybe we
> > > > should move this flag
> > > > > > > >> Add a skb->devmem flag which indicates whether the frags in
> > > > > > > >> this skb
> > > > > > > >> are device memory frags or not.
> > > > >
On Mon, Nov 6, 2023 at 3:55 PM David Ahern wrote:
>
> On 11/6/23 4:32 PM, Stanislav Fomichev wrote:
> >> The concise notification API returns tokens as a range for
> >> compression, encoding as two 32-bit unsigned integers start + length.
> >> It allows for even further batching by returning multi
On Mon, Nov 6, 2023 at 2:34 PM Stanislav Fomichev wrote:
>
> On 11/06, Willem de Bruijn wrote:
> > > > IMHO, we need a better UAPI to receive the tokens and give them back to
> > > > the kernel. CMSG + setsockopt(SO_DEVMEM_DONTNEED) get the job done,
&g
> > IMHO, we need a better UAPI to receive the tokens and give them back to
> > the kernel. CMSG + setsockopt(SO_DEVMEM_DONTNEED) get the job done,
> > but look dated and hacky :-(
> >
> > We should either do some kind of user/kernel shared memory queue to
> > receive/return the tokens (similar to
On Mon, Aug 21, 2023 at 5:31 PM Jakub Kicinski wrote:
>
> On Sat, 19 Aug 2023 12:12:16 -0400 Willem de Bruijn wrote:
> > :-) For the record, there is a prior version that added a separate type.
> >
> > I did not like the churn it brought and asked for this.
>
> It do
On Sat, Aug 19, 2023 at 11:49 AM David Ahern wrote:
>
> On 8/19/23 9:22 AM, Jesper Dangaard Brouer wrote:
> >
> > I do see the problem of depending on having a struct page, as the
> > page_pool_iov isn't related to struct page. Having "page" in the name
> > of "page_pool_iov" is also confusing (h
On Sat, Aug 19, 2023 at 5:51 AM Jesper Dangaard Brouer
wrote:
>
>
>
> On 10/08/2023 03.57, Mina Almasry wrote:
> > Overload the LSB of struct page* to indicate that it's a page_pool_iov.
> >
> > Refactor mm calls on struct page * into helpers, and add page_pool_iov
> > handling on those helpers. M
> > Any regression in page pool can be avoided in the common case that
> > does not use device mem by placing that behind a static_branch. Would
> > that address your performance concerns?
> >
>
> No. This will not help.
>
> The problem is that every where in the page_pool code it is getting
> poll
On Tue, Aug 15, 2023 at 9:38 AM David Laight wrote:
>
> From: Mina Almasry
> > Sent: 10 August 2023 02:58
> ...
> > * TL;DR:
> >
> > Device memory TCP (devmem TCP) is a proposal for transferring data to and/or
> > from device memory efficiently, without bouncing the data to a host memory
> > buffe
On Wed, Oct 2, 2019 at 5:45 PM syzbot
wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:a32db7e1 Add linux-next specific files for 20191002
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=175ab7cd60
> kernel config: https:/
On Wed, Oct 2, 2019 at 3:56 PM syzbot
wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:a32db7e1 Add linux-next specific files for 20191002
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=175ab7cd60
> kernel config: https:/
14 matches
Mail list logo
