All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vlad Yasevich <vyasevich@gmail.com>
To: John Fastabend <john.r.fastabend@intel.com>,
	nhorman@tuxdriver.com, alexander.h.duyck@intel.com
Cc: netdev@vger.kernel.org, andy@greyhouse.net, davem@davemloft.net,
	jeffrey.t.kirsher@intel.com
Subject: Re: [PATCH v2 0/2] l2 hardware accelerated macvlans
Date: Tue, 05 Nov 2013 09:47:55 -0500	[thread overview]
Message-ID: <5279051B.6000406@gmail.com> (raw)
In-Reply-To: <20131104185717.11802.69282.stgit@jf-dev1-dcblab>

Hi John

On 11/04/2013 02:01 PM, John Fastabend wrote:
> This patch adds support to offload macvlan net_devices to the
> hardware. With these patches packets are pushed to the macvlan
> net_device directly and do not pass through the lower dev.
>
> The patches here have made it through multiple iterations
> each with a slightly different focus. First I tried to
> push these as a new link type called "VMDQ". The patches
> shown here,
>
> http://comments.gmane.org/gmane.linux.network/237617
>
> Following this implementation I renamed the link type
> "VSI" and addressed various comments. Finally Neil
> Horman picked up the patches and integrated the offload
> into the macvlan code. Here,
>
> http://permalink.gmane.org/gmane.linux.network/285658
>
> The attached series is clean-up of his patches, with a
> few fixes. I suspect Neil will add his signed-off-by
> line assuming I didn't mangle anything.
>
> If folks find this series acceptable there are a few
> items we can work on next. First broadcast and multicast
> will use the hardware even for local traffic with this
> series. It would be best (I think) to use the software
> path for macvlan to macvlan traffic and save the PCIe
> bus. Also this only allows for layer 2 mac forwarding
> where some hardware supports more interesting forwarding
> capabilities. Integrating with OVS may be useful here.

This seems to be saying that for macvlan-macvlan
case, you still prefere to do software based forwarding, but
patch 1 in the series seem to always attempt to do hardware
offloaded forwarding regardless of traffic and macvlan type.
Can you clarify.

Thanks
-vlad

>
> As always any comments/feedback welcome.
>
> I'm going to continue testing these on top of ixgbe but
> I believe these are stable and wanted to get them out to
> a wider audience. I've tested multiple offloaded macvlans
> with iperf and netperf using multiple sessions of each
> and seen no issues.
>
> My basic I/O test is here but I've also done some link
> testing and others,
>
> #ip link add link eth2 numtxqueues 4 numrxqueues 4 txqueuelen 50 type macvlan
> #tc qdisc add dev macvlan0 mq
> #iperf -c 10.0.0.1 -P 8 -t 5000 -i 10
>
> Changelog:
> v2: two fixes to ixgbe when all features DCB, FCoE, SR-IOV
>      are enabled with macvlans. A VMDQ_P() reference
>      should have been accel->pool and do not set the offset
>      of the ring index from dfwd add call. The offset is used
>      by SR-IOV so clearing it can cause SR-IOV quue index's
>      to go sideways. With these fixes testing macvlan's with
>      SRIOV enabled was successful.
>
> Thanks,
> John
>
> ---
>
> John Fastabend (2):
>        ixgbe: enable l2 forwarding acceleration for macvlans
>        net: Add layer 2 hardware acceleration operations for macvlan devices
>
>
>   drivers/net/ethernet/intel/ixgbe/ixgbe.h      |   20 +
>   drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c  |   12 +
>   drivers/net/ethernet/intel/ixgbe/ixgbe_main.c |  463 +++++++++++++++++++++----
>   drivers/net/macvlan.c                         |   36 ++
>   include/linux/if_macvlan.h                    |    1
>   include/linux/netdev_features.h               |    2
>   include/linux/netdevice.h                     |   36 ++
>   include/uapi/linux/if.h                       |    1
>   net/core/dev.c                                |   18 +
>   net/core/ethtool.c                            |    1
>   net/sched/sch_generic.c                       |    2
>   11 files changed, 504 insertions(+), 88 deletions(-)
>

  parent reply	other threads:[~2013-11-05 14:48 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-04 19:01 [PATCH v2 0/2] l2 hardware accelerated macvlans John Fastabend
2013-11-04 19:01 ` [PATCH v2 1/2] net: Add layer 2 hardware acceleration operations for macvlan devices John Fastabend
2013-11-05 14:15   ` Neil Horman
2013-11-04 19:01 ` [PATCH v2 2/2] ixgbe: enable l2 forwarding acceleration for macvlans John Fastabend
2013-11-05  6:24   ` John Fastabend
2013-11-05 14:26   ` Neil Horman
2013-11-05 20:34     ` John Fastabend
2013-11-05 20:52       ` Neil Horman
2013-11-05 14:47 ` Vlad Yasevich [this message]
2013-11-05 15:17   ` [PATCH v2 0/2] l2 hardware accelerated macvlans John Fastabend
2013-11-05 15:20     ` Vlad Yasevich

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=5279051B.6000406@gmail.com \
    --to=vyasevich@gmail.com \
    --cc=alexander.h.duyck@intel.com \
    --cc=andy@greyhouse.net \
    --cc=davem@davemloft.net \
    --cc=jeffrey.t.kirsher@intel.com \
    --cc=john.r.fastabend@intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=nhorman@tuxdriver.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.