and some fixes are needed.
>
> Admittedly more code could be extracted but I only had
> the time for a minor cleanup :(
Acked-by: Stanislav Fomichev
Far too often I've seen this test broken because it's not in the CI :-(
Hope you can put it in the netdev one so we get a better signal.
ference to it.
>
> Signed-off-by: Jose Fernandez
> Reviewed-by: Tycho Andersen
Acked-by: Stanislav Fomichev
On 03/15, Jose Fernandez wrote:
> This patch enhances the BPF helpers by adding a kfunc to retrieve the
> cgroup v2 ID of a specific task, addressing a previous limitation where
> only bpf_task_get_cgroup1 was available for cgroup v1. The new kfunc is
> particularly useful for scenarios where
s * 500 = 5ms should be enough for packet transmission and status
> retrival.
>
> Signed-off-by: Song Yoong Siang
Acked-by: Stanislav Fomichev
On 12/29, Menglong Dong wrote:
> For now, we have to call some helpers when we need to update the csum,
> such as bpf_l4_csum_replace, bpf_l3_csum_replace, etc. These helpers are
> not inlined, which causes poor performance.
>
> In fact, we can define our own csum update functions in BPF program
On 12/06, Magnus Karlsson wrote:
> On Tue, 5 Dec 2023 at 20:39, Stanislav Fomichev wrote:
> >
> > On 12/05, Willem de Bruijn wrote:
> > > Stanislav Fomichev wrote:
> > > > On Tue, Dec 5, 2023 at 7:34 AM Florian Bezdeka
> > > > wrote:
> > &
On 12/05, Willem de Bruijn wrote:
> Stanislav Fomichev wrote:
> > On Tue, Dec 5, 2023 at 7:34 AM Florian Bezdeka
> > wrote:
> > >
> > > On Tue, 2023-12-05 at 15:25 +, Song, Yoong Siang wrote:
> > > > On Monday, December 4, 2023 10:55 PM, Will
On Tue, Dec 5, 2023 at 7:34 AM Florian Bezdeka
wrote:
>
> On Tue, 2023-12-05 at 15:25 +, Song, Yoong Siang wrote:
> > On Monday, December 4, 2023 10:55 PM, Willem de Bruijn wrote:
> > > Jesper Dangaard Brouer wrote:
> > > >
> > > >
> > > > On 12/3/23 17:51, Song Yoong Siang wrote:
> > > > >
On 11/11, Jordan Rome wrote:
> This is a follow up to:
> commit b8e3a87a627b ("bpf: Add crosstask check to __bpf_get_stack").
>
> This test ensures that the task iterator only gets a single
> user stack (for the current task).
>
> Signed-off-by: Jordan Rome
On 11/07, Eric Dumazet wrote:
> On Tue, Nov 7, 2023 at 10:05 PM Stanislav Fomichev wrote:
>
> >
> > I don't understand. We require an elaborate setup to receive devmem cmsgs,
> > why would some random application receive those?
>
>
> A TCP socket can rece
On 11/07, Mina Almasry wrote:
> On Mon, Nov 6, 2023 at 5:06 PM Stanislav Fomichev wrote:
> [..]
> > > > > And the socket has to know this association; otherwise those tokens
> > > > > are useless since they don't carry anything to identify the dmabuf.
> &
On 11/07, Willem de Bruijn wrote:
> 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
> > > > > > > th
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 passing it
> > > > > for an individual system call.
> > > > > If we know that we're going to use dmabuf with the
On 11/06, Mina Almasry wrote:
> On Mon, Nov 6, 2023 at 4:08 PM Willem de Bruijn
> wrote:
> >
> > On Mon, Nov 6, 2023 at 3:55 PM Stanislav Fomichev wrote:
> > >
> > > On Mon, Nov 6, 2023 at 3:27 PM Mina Almasry
> > > wrote:
> > > >
On 11/06, Stanislav Fomichev wrote:
> On 11/06, Willem de Bruijn wrote:
> > On Mon, Nov 6, 2023 at 3:55 PM Stanislav Fomichev wrote:
> > >
> > > On Mon, Nov 6, 2023 at 3:27 PM Mina Almasry
> > > wrote:
> > > >
> > > > On Mo
On 11/06, Willem de Bruijn wrote:
> On Mon, Nov 6, 2023 at 3:55 PM Stanislav Fomichev wrote:
> >
> > On Mon, Nov 6, 2023 at 3:27 PM Mina Almasry wrote:
> > >
> > > On Mon, Nov 6, 2023 at 2:59 PM Stanislav Fomichev wrote:
> > > >
> > > &
On Mon, Nov 6, 2023 at 3:27 PM Mina Almasry wrote:
>
> On Mon, Nov 6, 2023 at 2:59 PM Stanislav Fomichev wrote:
> >
> > On 11/06, Mina Almasry wrote:
> > > On Mon, Nov 6, 2023 at 1:59 PM Stanislav Fomichev wrote:
> > > >
> > > > On 11/06, Mina
On Mon, Nov 6, 2023 at 2:56 PM Willem de Bruijn
wrote:
>
> 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
> > > >
On 11/06, Mina Almasry wrote:
> On Mon, Nov 6, 2023 at 1:59 PM Stanislav Fomichev wrote:
> >
> > On 11/06, Mina Almasry wrote:
> > > On Mon, Nov 6, 2023 at 11:34 AM David Ahern wrote:
> > > >
> > > > On 11/6/23 11:47 AM, Stanislav Fomich
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,
> > > but look dated and hacky :-(
> > >
> > > We should either do some kind of user/kernel shared memory queue
On 11/06, Mina Almasry wrote:
> On Mon, Nov 6, 2023 at 11:34 AM David Ahern wrote:
> >
> > On 11/6/23 11:47 AM, Stanislav Fomichev wrote:
> > > On 11/05, Mina Almasry wrote:
> > >> For device memory TCP, we expect the skb headers to be available in host
>
On 11/06, Mina Almasry wrote:
> On Mon, Nov 6, 2023 at 10:44 AM Stanislav Fomichev wrote:
> >
> > On 11/05, Mina Almasry wrote:
> > > In tcp_recvmsg_locked(), detect if the skb being received by the user
> > > is a devmem skb. In this case - if the user provid
On 11/05, Mina Almasry wrote:
> Implement a memory provider that allocates dmabuf devmem page_pool_iovs.
>
> Support of PP_FLAG_DMA_MAP and PP_FLAG_DMA_SYNC_DEV is omitted for
> simplicity.
>
> The provider receives a reference to the struct netdev_dmabuf_binding
> via the pool->mp_priv pointer.
On 11/05, Mina Almasry wrote:
> For device memory TCP, we expect the skb headers to be available in host
> memory for access, and we expect the skb frags to be in device memory
> and unaccessible to the host. We expect there to be no mixing and
> matching of device memory frags (unaccessible) with
On 11/05, Mina Almasry wrote:
> For device memory TCP, we expect the skb headers to be available in host
> memory for access, and we expect the skb frags to be in device memory
> and unaccessible to the host. We expect there to be no mixing and
> matching of device memory frags (unaccessible) with
On 11/05, Mina Almasry wrote:
> In tcp_recvmsg_locked(), detect if the skb being received by the user
> is a devmem skb. In this case - if the user provided the MSG_SOCK_DEVMEM
> flag - pass it to tcp_recvmsg_devmem() for custom handling.
>
> tcp_recvmsg_devmem() copies any data in the skb header
26 matches
Mail list logo
