[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOJe8K3AaGFAPYymu4FW4OhXnhnxQUhA18m4OLp_66EVj6LxEA@mail.gmail.com>
Date: Fri, 6 Mar 2020 12:48:26 +0300
From: Denis Kirjanov <kda@...ux-powerpc.org>
To: Jesper Dangaard Brouer <brouer@...hat.com>
Cc: netdev@...r.kernel.org, jgross@...e.com,
ilias.apalodimas@...aro.org
Subject: Re: [PATCH net-next v2] xen-netfront: add basic XDP support
On 3/5/20, Jesper Dangaard Brouer <brouer@...hat.com> wrote:
> On Mon, 2 Mar 2020 17:21:14 +0300
> Denis Kirjanov <kda@...ux-powerpc.org> wrote:
>
>> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
>> index 482c6c8..db8a280 100644
>> --- a/drivers/net/xen-netfront.c
>> +++ b/drivers/net/xen-netfront.c
> [...]
>> @@ -778,6 +782,40 @@ static int xennet_get_extras(struct netfront_queue
>> *queue,
>> return err;
>> }
>>
>> +u32 xennet_run_xdp(struct netfront_queue *queue, struct page *pdata,
>> + struct xen_netif_rx_response *rx, struct bpf_prog *prog,
>> + struct xdp_buff *xdp)
>> +{
>> + u32 len = rx->status;
>> + u32 act = XDP_PASS;
>> +
>> + xdp->data_hard_start = page_address(pdata);
>> + xdp->data = xdp->data_hard_start + XDP_PACKET_HEADROOM;
>> + xdp_set_data_meta_invalid(xdp);
>> + xdp->data_end = xdp->data + len;
>> + xdp->handle = 0;
>> +
>> + act = bpf_prog_run_xdp(prog, xdp);
>> + switch (act) {
>> + case XDP_PASS:
>> + case XDP_TX:
>> + case XDP_DROP:
>> + break;
>> +
>> + case XDP_ABORTED:
>> + trace_xdp_exception(queue->info->netdev, prog, act);
>> + break;
>> +
>> + default:
>> + bpf_warn_invalid_xdp_action(act);
>> + }
>> +
>> + if (act != XDP_PASS && act != XDP_TX)
>> + xdp->data_hard_start = NULL;
>> +
>> + return act;
>> +}
>> +
>> static int xennet_get_responses(struct netfront_queue *queue,
>> struct netfront_rx_info *rinfo, RING_IDX rp,
>> struct sk_buff_head *list)
>> @@ -792,6 +830,9 @@ static int xennet_get_responses(struct netfront_queue
>> *queue,
>> int slots = 1;
>> int err = 0;
>> unsigned long ret;
>> + struct bpf_prog *xdp_prog;
>> + struct xdp_buff xdp;
>> + u32 verdict;
>>
>> if (rx->flags & XEN_NETRXF_extra_info) {
>> err = xennet_get_extras(queue, extras, rp);
>> @@ -827,6 +868,22 @@ static int xennet_get_responses(struct netfront_queue
>> *queue,
>>
>> gnttab_release_grant_reference(&queue->gref_rx_head, ref);
>>
>> + rcu_read_lock();
>> + xdp_prog = rcu_dereference(queue->xdp_prog);
>> + if (xdp_prog) {
>> + /* currently only a single page contains data */
>> + WARN_ON_ONCE(skb_shinfo(skb)->nr_frags != 1);
>> + verdict = xennet_run_xdp(queue,
>> + skb_frag_page(&skb_shinfo(skb)->frags[0]),
>
> This looks really weird, skb_shinfo(skb)->frags[0], you already have an
> SKB and you are sending fragment-0 to the xennet_run_xdp() function.
>
> XDP meant to run before an SKB is allocated...
Agreed. But the xen networking works that data communicated using
shared pages between backend and frontend parts.
So xen-netfront just allocates skbs with attached pages to them and
shares those pages with xen-netback
>
>> + rx, xdp_prog, &xdp);
>> +
>> + if (verdict != XDP_PASS && verdict != XDP_TX) {
>> + err = -EINVAL;
>> + goto next;
>> + }
>> +
>> + }
>> + rcu_read_unlock();
>> __skb_queue_tail(list, skb);
>
>
> --
> Best regards,
> Jesper Dangaard Brouer
> MSc.CS, Principal Kernel Engineer at Red Hat
> LinkedIn: http://www.linkedin.com/in/brouer
>
>
Powered by blists - more mailing lists