linux-kernel - RE: [PATCH V2,net-next, 1/2] hv

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: <MN2PR21MB1375A6F208BC94CD4CFA016BCA0D0@MN2PR21MB1375.namprd21.prod.outlook.com>
Date:   Tue, 21 Jan 2020 18:53:28 +0000
From:   Haiyang Zhang <haiyangz@...rosoft.com>
To:     David Miller <davem@...emloft.net>
CC:     "sashal@...nel.org" <sashal@...nel.org>,
        "linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        KY Srinivasan <kys@...rosoft.com>,
        Stephen Hemminger <sthemmin@...rosoft.com>,
        "olaf@...fle.de" <olaf@...fle.de>, vkuznets <vkuznets@...hat.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH V2,net-next, 1/2] hv_netvsc: Add XDP support

Sorry I was replying too quickly. See more detailed explanation below.

> -----Original Message-----
> From: linux-hyperv-owner@...r.kernel.org <linux-hyperv-
> owner@...r.kernel.org> On Behalf Of David Miller
> Sent: Tuesday, January 21, 2020 5:05 AM
> To: Haiyang Zhang <haiyangz@...rosoft.com>
> Cc: sashal@...nel.org; linux-hyperv@...r.kernel.org; netdev@...r.kernel.org;
> KY Srinivasan <kys@...rosoft.com>; Stephen Hemminger
> <sthemmin@...rosoft.com>; olaf@...fle.de; vkuznets
> <vkuznets@...hat.com>; linux-kernel@...r.kernel.org
> Subject: Re: [PATCH V2,net-next, 1/2] hv_netvsc: Add XDP support
> 
> From: Haiyang Zhang <haiyangz@...rosoft.com>
> Date: Mon, 20 Jan 2020 14:22:36 -0800
> 
> > +u32 netvsc_run_xdp(struct net_device *ndev, struct netvsc_channel *nvchan,
> > +		   struct xdp_buff *xdp)
> > +{
> > +	struct page *page = NULL;
> > +	void *data = nvchan->rsc.data[0];
> > +	u32 len = nvchan->rsc.len[0];
> > +	struct bpf_prog *prog;
> > +	u32 act = XDP_PASS;
> 
> Please use reverse christmas tree ordering of local variables.
Will do.

> 
> > +	xdp->data_hard_start = page_address(page);
> > +	xdp->data = xdp->data_hard_start + NETVSC_XDP_HDRM;
> > +	xdp_set_data_meta_invalid(xdp);
> > +	xdp->data_end = xdp->data + len;
> > +	xdp->rxq = &nvchan->xdp_rxq;
> > +	xdp->handle = 0;
> > +
> > +	memcpy(xdp->data, data, len);
> 
> Why can't the program run directly on nvchan->rsc.data[0]?

The Azure/Hyper-V synthetic NIC receive buffer doesn't provide headroom 
for XDP. We thought about re-use the RNDIS header space, but it's too 
small. So we decided to copy the packets to a page buffer for XDP. And, 
most of our VMs on Azure have Accelerated  Network (SRIOV) enabled, so 
most of the packets run on VF NIC. The synthetic NIC is considered as a 
fallback data-path. So the data copy on netvsc won't impact performance 
significantly.

Thanks,
- Haiyang