Netdev List
 help / color / mirror / Atom feed
From: Shannon Nelson <shannon.nelson@oracle.com>
To: Alexander Duyck <alexander.h.duyck@intel.com>,
	intel-wired-lan@lists.osuosl.org, jeffrey.t.kirsher@intel.com
Cc: netdev@vger.kernel.org
Subject: Re: [Intel-wired-lan] [iwl next-queue PATCH 03/10] macvlan: Use software path for offloaded local, broadcast, and multicast traffic
Date: Wed, 4 Apr 2018 09:53:26 -0700	[thread overview]
Message-ID: <a99a73c2-1216-30ba-9d86-9bb4626a8a81@oracle.com> (raw)
In-Reply-To: <20180403211609.7880.1015.stgit@ahduyck-green-test.jf.intel.com>

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@intel.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

  reply	other threads:[~2018-04-04 16:53 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-03 21:15 [iwl next-queue PATCH 00/10] Clean-up macvlan offloading Alexander Duyck
2018-04-03 21:15 ` [iwl next-queue PATCH 01/10] ixgbe: Drop support for macvlan specific unicast lists Alexander Duyck
2018-04-03 21:16 ` [iwl next-queue PATCH 02/10] macvlan: Rename fwd_priv to accel_priv and add accessor function Alexander Duyck
2018-04-04 16:53   ` [Intel-wired-lan] " Shannon Nelson
2018-04-04 17:33     ` Alexander Duyck
2018-04-03 21:16 ` [iwl next-queue PATCH 03/10] macvlan: Use software path for offloaded local, broadcast, and multicast traffic Alexander Duyck
2018-04-04 16:53   ` Shannon Nelson [this message]
2018-04-04 17:02     ` [Intel-wired-lan] " Alexander Duyck
2018-04-03 21:16 ` [iwl next-queue PATCH 04/10] ixgbe/fm10k: Drop tracking stats for macvlan broadcast/multicast Alexander Duyck
2018-04-03 21:16 ` [iwl next-queue PATCH 05/10] macvlan: macvlan_count_rx shouldn't be static inline AND extern Alexander Duyck
2018-04-03 21:16 ` [iwl next-queue PATCH 06/10] macvlan: Add function to test for destination filtering support Alexander Duyck
2018-04-03 21:16 ` [iwl next-queue PATCH 07/10] macvlan: Provide function for interfaces to release HW offload Alexander Duyck
2018-04-03 21:16 ` [iwl next-queue PATCH 08/10] ixgbe/fm10k: Only support macvlan offload for types that support destination filtering Alexander Duyck
2018-04-03 21:16 ` [iwl next-queue PATCH 09/10] ixgbe: Drop real_adapter from l2 fwd acceleration structure Alexander Duyck
2018-04-03 21:16 ` [iwl next-queue PATCH 10/10] ixgbe: Avoid performing unnecessary resets for macvlan offload Alexander Duyck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a99a73c2-1216-30ba-9d86-9bb4626a8a81@oracle.com \
    --to=shannon.nelson@oracle.com \
    --cc=alexander.h.duyck@intel.com \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=jeffrey.t.kirsher@intel.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox