netdev - Re: [Intel-wired-lan] [iwl next-queue PATCH 03/10] macvlan: Use software path for offloaded local, broadcast, and multicast traffic

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: <a99a73c2-1216-30ba-9d86-9bb4626a8a81@oracle.com>
Date:   Wed, 4 Apr 2018 09:53:26 -0700
From:   Shannon Nelson <shannon.nelson@...cle.com>
To:     Alexander Duyck <alexander.h.duyck@...el.com>,
        intel-wired-lan@...ts.osuosl.org, jeffrey.t.kirsher@...el.com
Cc:     netdev@...r.kernel.org
Subject: Re: [Intel-wired-lan] [iwl next-queue PATCH 03/10] macvlan: Use
 software path for offloaded local, broadcast, and multicast traffic

On 4/3/2018 2:16 PM, Alexander Duyck wrote:
> This change makes it so that we use a software path for packets that are
> going to be locally switched between two macvlan interfaces on the same
> device. In addition we resort to software replication of broadcast and
> multicast packets instead of offloading that to hardware.
> 
> The general idea is that using the device for east/west traffic local to
> the system is extremely inefficient. We can only support up to whatever the
> PCIe limit is for any given device so this caps us at somewhere around 20G
> for devices supported by ixgbe. This is compounded even further when you
> take broadcast and multicast into account as a single 10G port can come to
> a crawl as a packet is replicated up to 60+ times in some cases. In order
> to get away from that I am implementing changes so that we handle
> broadcast/multicast replication and east/west local traffic all in
> software.
> 
> Signed-off-by: Alexander Duyck <alexander.h.duyck@...el.com>
> ---

[...]

>   
> @@ -4225,6 +4226,13 @@ static void ixgbe_configure_virtualization(struct ixgbe_adapter *adapter)
>   	vmdctl |= IXGBE_VT_CTL_REPLEN;
>   	IXGBE_WRITE_REG(hw, IXGBE_VT_CTL, vmdctl);
>   
> +	/* accept untagged packets until a vlan tag is
> +	 * specifically set for the VMDQ queue/pool
> +	 */
> +	vmolr = IXGBE_VMOLR_AUPE;
> +	while (pool--)
> +		IXGBE_WRITE_REG(hw, IXGBE_VMOLR(VMDQ_P(pool)), vmolr);
> +

It took me a bit to figure out what untagged packets have to do with 
macvlan config.  You might add to the comment that "no multicast or 
broadcast is configured for these queues".

The driver part of this might be separated into a follow-on patch to 
make it clearer that this is done as a consequence of the macvlan.c 
changes.  Or just roll them into your 4/10 patch.

sln