netdev.vger.kernel.org archive mirror
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).