search for: xdpf

...int virtnet_xdp_handler(struct bpf_prog *xdp_prog, struct xdp_buff *xdp, > + struct net_device *dev, > + unsigned int *xdp_xmit, > + struct virtnet_rq_stats *stats) > +{ > + struct xdp_frame *xdpf; > + int err; > + u32 act; > + > + act = bpf_prog_run_xdp(xdp_prog, xdp); > + stats->xdp_packets++; > + > + switch (act) { > + case XDP_PASS: > + return VIRTNET_XDP_RES_PASS; > + > + case XDP_TX: > +...

...> XDP_TX/XDP_REDIRECTION goes for this. > > So t virtnet_xdp_handler() just maps XDP ACTION plus the error > conditions to the above three states. > > We can simply map error to XDP_DROP like: > > case XDP_TX: > stats->xdp_tx++; > xdpf = xdp_convert_buff_to_frame(xdp); > if (unlikely(!xdpf)) > return XDP_DROP; > > A good side effect is to avoid the xdp_xmit pointer to be passed to > the function. So, I guess you mean this: switch (act) { case XDP_PASS: /* handle pass */...

...t; > > > So t virtnet_xdp_handler() just maps XDP ACTION plus the error > > conditions to the above three states. > > > > We can simply map error to XDP_DROP like: > > > > case XDP_TX: > > stats->xdp_tx++; > > xdpf = xdp_convert_buff_to_frame(xdp); > > if (unlikely(!xdpf)) > > return XDP_DROP; > > > > A good side effect is to avoid the xdp_xmit pointer to be passed to > > the function. > > > So, I guess you mean this: > >...

...the error > > > > conditions to the above three states. > > > > > > > > We can simply map error to XDP_DROP like: > > > > > > > > case XDP_TX: > > > > stats->xdp_tx++; > > > > xdpf = xdp_convert_buff_to_frame(xdp); > > > > if (unlikely(!xdpf)) > > > > return XDP_DROP; > > > > > > > > A good side effect is to avoid the xdp_xmit pointer to be passed to > > > > the function. > &g...

...xdp_tx_drops; - } tx; }; #define VIRTNET_SQ_STAT(m) offsetof(struct virtnet_sq_stats, m) @@ -485,22 +481,6 @@ static struct send_queue *virtnet_xdp_sq(struct virtnet_info *vi) return &vi->sq[qp]; } -static int __virtnet_xdp_tx_xmit(struct virtnet_info *vi, - struct xdp_frame *xdpf) -{ - struct xdp_frame *xdpf_sent; - struct send_queue *sq; - unsigned int len; - - sq = virtnet_xdp_sq(vi); - - /* Free up any pending old buffers before queueing new ones. */ - while ((xdpf_sent = virtqueue_get_buf(sq->vq, &len)) != NULL) - xdp_return_frame(xdpf_sent); - - return __virtne...

...xdp_tx_drops; - } tx; }; #define VIRTNET_SQ_STAT(m) offsetof(struct virtnet_sq_stats, m) @@ -485,22 +481,6 @@ static struct send_queue *virtnet_xdp_sq(struct virtnet_info *vi) return &vi->sq[qp]; } -static int __virtnet_xdp_tx_xmit(struct virtnet_info *vi, - struct xdp_frame *xdpf) -{ - struct xdp_frame *xdpf_sent; - struct send_queue *sq; - unsigned int len; - - sq = virtnet_xdp_sq(vi); - - /* Free up any pending old buffers before queueing new ones. */ - while ((xdpf_sent = virtqueue_get_buf(sq->vq, &len)) != NULL) - xdp_return_frame(xdpf_sent); - - return __virtne...

...(-) diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c index a3f2bcb3db27..136131a7868a 100644 --- a/drivers/net/virtio_net.c +++ b/drivers/net/virtio_net.c @@ -833,14 +833,14 @@ static int virtnet_xdp_handler(struct bpf_prog *xdp_prog, struct xdp_buff *xdp, stats->xdp_tx++; xdpf = xdp_convert_buff_to_frame(xdp); if (unlikely(!xdpf)) - return VIRTNET_XDP_RES_DROP; + goto drop; err = virtnet_xdp_xmit(dev, 1, &xdpf, 0); if (unlikely(!err)) { xdp_return_frame_rx_napi(xdpf); } else if (unlikely(err < 0)) { trace_xdp_exception(dev, xdp_prog, act)...

...rtio_net.c b/drivers/net/virtio_net.c > index a3f2bcb3db27..136131a7868a 100644 > --- a/drivers/net/virtio_net.c > +++ b/drivers/net/virtio_net.c > @@ -833,14 +833,14 @@ static int virtnet_xdp_handler(struct bpf_prog *xdp_prog, struct xdp_buff *xdp, > stats->xdp_tx++; > xdpf = xdp_convert_buff_to_frame(xdp); > if (unlikely(!xdpf)) > - return VIRTNET_XDP_RES_DROP; > + goto drop; > > err = virtnet_xdp_xmit(dev, 1, &xdpf, 0); > if (unlikely(!err)) { > xdp_return_frame_rx_napi(xdpf); > } else if (unlikely(err < 0))...

Due to historical reasons, the implementation of XDP in virtio-net is relatively chaotic. For example, the processing of XDP actions has two copies of similar code. Such as page, xdp_page processing, etc. The purpose of this patch set is to refactor these code. Reduce the difficulty of subsequent maintenance. Subsequent developers will not introduce new bugs because of some complex logical

Due to historical reasons, the implementation of XDP in virtio-net is relatively chaotic. For example, the processing of XDP actions has two copies of similar code. Such as page, xdp_page processing, etc. The purpose of this patch set is to refactor these code. Reduce the difficulty of subsequent maintenance. Subsequent developers will not introduce new bugs because of some complex logical

Due to historical reasons, the implementation of XDP in virtio-net is relatively chaotic. For example, the processing of XDP actions has two copies of similar code. Such as page, xdp_page processing, etc. The purpose of this patch set is to refactor these code. Reduce the difficulty of subsequent maintenance. Subsequent developers will not introduce new bugs because of some complex logical

...dp); - stats->rx.xdp_packets++; + stats->xdp_packets++; switch (act) { case XDP_PASS: @@ -683,7 +675,7 @@ static struct sk_buff *receive_small(struct net_device *dev, len = xdp.data_end - xdp.data; break; case XDP_TX: - stats->rx.xdp_tx++; + stats->xdp_tx++; xdpf = convert_to_xdp_frame(&xdp); if (unlikely(!xdpf)) goto err_xdp; @@ -696,7 +688,7 @@ static struct sk_buff *receive_small(struct net_device *dev, rcu_read_unlock(); goto xdp_xmit; case XDP_REDIRECT: - stats->rx.xdp_redirects++; + stats->xdp_redirects++; err = x...

...his removed, the compare between packed vs >> split is kind of unfair. > I don't think this ever triggers to be frank. When would it? I think it can happen e.g in the path of XDP transmission in __virtnet_xdp_xmit_one(): ??????? err = virtqueue_add_outbuf(sq->vq, sq->sg, 1, xdpf, GFP_ATOMIC); ??????? if (unlikely(err)) ??????????????? return -ENOSPC; /* Caller handle free/refcnt */ > >> Consider the removal of lguest support recently, >> maybe we can drop this for split ring as well? >> >> Thanks > If it's helpful, then for sure we can...

...his removed, the compare between packed vs >> split is kind of unfair. > I don't think this ever triggers to be frank. When would it? I think it can happen e.g in the path of XDP transmission in __virtnet_xdp_xmit_one(): ??????? err = virtqueue_add_outbuf(sq->vq, sq->sg, 1, xdpf, GFP_ATOMIC); ??????? if (unlikely(err)) ??????????????? return -ENOSPC; /* Caller handle free/refcnt */ > >> Consider the removal of lguest support recently, >> maybe we can drop this for split ring as well? >> >> Thanks > If it's helpful, then for sure we can...

...tr))) { > struct sk_buff *skb = ptr; > > @@ -667,8 +773,7 @@ static int __virtnet_xdp_xmit_one(struct virtnet_info *vi, > skb_frag_size(frag), skb_frag_off(frag)); > } > > - err = virtqueue_add_outbuf(sq->vq, sq->sg, nr_frags + 1, > - xdp_to_ptr(xdpf), GFP_ATOMIC); > + err = virtnet_add_outbuf(sq, nr_frags + 1, xdp_to_ptr(xdpf)); > if (unlikely(err)) > return -ENOSPC; /* Caller handle free/refcnt */ > > @@ -744,7 +849,7 @@ static int virtnet_xdp_xmit(struct net_device *dev, > } > > /* Free up any pending old...

If the queue of xdp xmit is not an independent queue, then when the xdp xmit used all the desc, the xmit from the __dev_queue_xmit() may encounter the following error. net ens4: Unexpected TXQ (0) queue failure: -28 This patch adds a check whether sq is full in XDP Xmit. Thanks. v1: 1. rename to check_sq_full_and_disable 2. reorder some funcs to avoid declaration Xuan Zhuo (3):

...gt; > > split is kind of unfair. > > I don't think this ever triggers to be frank. When would it? > > > I think it can happen e.g in the path of XDP transmission in > __virtnet_xdp_xmit_one(): > > > ??????? err = virtqueue_add_outbuf(sq->vq, sq->sg, 1, xdpf, GFP_ATOMIC); > ??????? if (unlikely(err)) > ??????????????? return -ENOSPC; /* Caller handle free/refcnt */ > I see. We used to do it for regular xmit but stopped doing it. Is it fine for xdp then? > > > > > Consider the removal of lguest support recently, > > &gt...

On 2018/11/8 ??9:38, Tiwei Bie wrote: >>> + >>> + if (vq->vq.num_free < descs_used) { >>> + pr_debug("Can't add buf len %i - avail = %i\n", >>> + descs_used, vq->vq.num_free); >>> + /* FIXME: for historical reasons, we force a notify here if >>> + * there are outgoing parts to the buffer. Presumably the

On 2018/11/8 ??9:38, Tiwei Bie wrote: >>> + >>> + if (vq->vq.num_free < descs_used) { >>> + pr_debug("Can't add buf len %i - avail = %i\n", >>> + descs_used, vq->vq.num_free); >>> + /* FIXME: for historical reasons, we force a notify here if >>> + * there are outgoing parts to the buffer. Presumably the

## About DMA APIs Now, virtio may can not work with DMA APIs when virtio features do not have VIRTIO_F_ACCESS_PLATFORM. 1. I tried to let DMA APIs return phy address by virtio-device. But DMA APIs just work with the "real" devices. 2. I tried to let xsk support callballs to get phy address from virtio-net driver as the dma address. But the maintainers of xsk may want to use