netdev - Re: [RFC net-next v1 04/12] virtio_ring: perform premapped operations based on per-buffer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1727166134.9448166-1-xuanzhuo@linux.alibaba.com>
Date: Tue, 24 Sep 2024 16:22:14 +0800
From: Xuan Zhuo <xuanzhuo@...ux.alibaba.com>
To: Jason Wang <jasowang@...hat.com>
Cc: netdev@...r.kernel.org,
 "Michael S. Tsirkin" <mst@...hat.com>,
 Eugenio Pérez <eperezma@...hat.com>,
 "David S. Miller" <davem@...emloft.net>,
 Eric Dumazet <edumazet@...gle.com>,
 Jakub Kicinski <kuba@...nel.org>,
 Paolo Abeni <pabeni@...hat.com>,
 Alexei Starovoitov <ast@...nel.org>,
 Daniel Borkmann <daniel@...earbox.net>,
 Jesper Dangaard Brouer <hawk@...nel.org>,
 John Fastabend <john.fastabend@...il.com>,
 virtualization@...ts.linux.dev,
 bpf@...r.kernel.org
Subject: Re: [RFC net-next v1 04/12] virtio_ring: perform premapped operations based on per-buffer

On Tue, 24 Sep 2024 15:35:01 +0800, Jason Wang <jasowang@...hat.com> wrote:
> On Tue, Sep 24, 2024 at 9:32 AM Xuan Zhuo <xuanzhuo@...ux.alibaba.com> wrote:
> >
> > The current configuration sets the virtqueue (vq) to premapped mode,
> > implying that all buffers submitted to this queue must be mapped ahead
> > of time. This presents a challenge for the virtnet send queue (sq): the
> > virtnet driver would be required to keep track of dma information for vq
> > size * 17, which can be substantial. However, if the premapped mode were
> > applied on a per-buffer basis, the complexity would be greatly reduced.
> > With AF_XDP enabled, AF_XDP buffers would become premapped, while kernel
> > skb buffers could remain unmapped.
> >
> > We can distinguish them by sg_page(sg), When sg_page(sg) is NULL, this
> > indicates that the driver has performed DMA mapping in advance, allowing
> > the Virtio core to directly utilize sg_dma_address(sg) without
> > conducting any internal DMA mapping. Additionally, DMA unmap operations
> > for this buffer will be bypassed.
>
> So I think we still need some explanation here. I think this works for
> virtio-net as the sgs are initialized by the virtio-net device itself.
>
> But it seems not the case for all the others where the sgs were passed
> from the uppyer subsystem. For example in __virtscsi_add_cmd(), we
> had:
>
>         if (sc && sc->sc_data_direction != DMA_NONE) {
>         if (sc->sc_data_direction != DMA_FROM_DEVICE)
>                 out = &sc->sdb.table;
>         if (sc->sc_data_direction != DMA_TO_DEVICE)
>                 in = &sc->sdb.table;
>         }
>
>         /* Request header.  */
>         sg_init_one(&req, &cmd->req, req_size);
>         sgs[out_num++] = &req;
>
>         /* Data-out buffer.  */
>         if (out) {
>                 /* Place WRITE protection SGLs before Data OUT payload */
>                 if (scsi_prot_sg_count(sc))
>                         sgs[out_num++] = scsi_prot_sglist(sc);
>                 sgs[out_num++] = out->sgl;
>         }


With this in mind, I think the new api is a suitable approach to avoid changing
sg.

Thanks.

>
> Thanks
>