mbox series

[ovs-dev,0/6] offload Linux LAG devices to the TC datapath

Message ID 1529588161-15934-1-git-send-email-john.hurley@netronome.com
Headers show
Series offload Linux LAG devices to the TC datapath | expand

Message

John Hurley June 21, 2018, 1:35 p.m. UTC
This patchset extends OvS TC and the linux-netdev implementation to
support the offloading of Linux Link Aggregation devices (LAG) and their
slaves. TC blocks are used to provide this offload. Blocks, in TC, group
together a series of qdiscs. If a filter is added to one of these qdiscs
then it applied to all. Similarly, if a packet is matched on one of the
grouped qdiscs then the stats for the entire block are increased. The
basis of the LAG offload is that the LAG master (attached to the OvS
bridge) and slaves that may exist outside of OvS are all added to the same
TC block. OvS can then control the filters and collect the stats on the
slaves via its interaction with the LAG master.

The TC API is extended within OvS to allow the addition of a block id to
ingress qdisc adds. Block ids are then assigned to each LAG master that is
attached to the OvS bridge. The linux netdev netlink socket is used to
monitor slave devices. If a LAG slave is found whose master is on the bridge
then it is added to the same block as its master. If the underlying slaves
belong to an offloadable device then the Linux LAG device can be offloaded
to hardware.

John Hurley (6):
  tc: allow offloading of block ids
  netdev-provider: add class op to get block_id
  rtnetlink: extend parser to include kind of master and slave
  netdev-linux: indicate if netdev is a LAG master
  netdev-linux: assign LAG devs to tc blocks
  netdev-linux: monitor and offload LAG slaves to TC

 lib/netdev-bsd.c         |   3 +-
 lib/netdev-dpdk.c        |   3 +-
 lib/netdev-dummy.c       |   3 +-
 lib/netdev-linux.c       | 128 ++++++++++++++++++++++++++++++++++++++++++++---
 lib/netdev-provider.h    |   4 ++
 lib/netdev-tc-offloads.c |  82 +++++++++++++++++++++++-------
 lib/netdev-vport.c       |   3 +-
 lib/netdev.c             |  10 ++++
 lib/netdev.h             |   1 +
 lib/rtnetlink.c          |  43 ++++++++++++++++
 lib/rtnetlink.h          |   4 ++
 lib/tc.c                 |  60 +++++++++++++++-------
 lib/tc.h                 |  12 ++---
 13 files changed, 305 insertions(+), 51 deletions(-)
 mode change 100644 => 100755 lib/rtnetlink.h

Comments

Ben Pfaff June 21, 2018, 4:15 p.m. UTC | #1
Simon, I see that you have reviewed these patches.  Are you handling
this series?

Thanks,

Ben.

On Thu, Jun 21, 2018 at 02:35:55PM +0100, John Hurley wrote:
> This patchset extends OvS TC and the linux-netdev implementation to
> support the offloading of Linux Link Aggregation devices (LAG) and their
> slaves. TC blocks are used to provide this offload. Blocks, in TC, group
> together a series of qdiscs. If a filter is added to one of these qdiscs
> then it applied to all. Similarly, if a packet is matched on one of the
> grouped qdiscs then the stats for the entire block are increased. The
> basis of the LAG offload is that the LAG master (attached to the OvS
> bridge) and slaves that may exist outside of OvS are all added to the same
> TC block. OvS can then control the filters and collect the stats on the
> slaves via its interaction with the LAG master.
> 
> The TC API is extended within OvS to allow the addition of a block id to
> ingress qdisc adds. Block ids are then assigned to each LAG master that is
> attached to the OvS bridge. The linux netdev netlink socket is used to
> monitor slave devices. If a LAG slave is found whose master is on the bridge
> then it is added to the same block as its master. If the underlying slaves
> belong to an offloadable device then the Linux LAG device can be offloaded
> to hardware.
> 
> John Hurley (6):
>   tc: allow offloading of block ids
>   netdev-provider: add class op to get block_id
>   rtnetlink: extend parser to include kind of master and slave
>   netdev-linux: indicate if netdev is a LAG master
>   netdev-linux: assign LAG devs to tc blocks
>   netdev-linux: monitor and offload LAG slaves to TC
> 
>  lib/netdev-bsd.c         |   3 +-
>  lib/netdev-dpdk.c        |   3 +-
>  lib/netdev-dummy.c       |   3 +-
>  lib/netdev-linux.c       | 128 ++++++++++++++++++++++++++++++++++++++++++++---
>  lib/netdev-provider.h    |   4 ++
>  lib/netdev-tc-offloads.c |  82 +++++++++++++++++++++++-------
>  lib/netdev-vport.c       |   3 +-
>  lib/netdev.c             |  10 ++++
>  lib/netdev.h             |   1 +
>  lib/rtnetlink.c          |  43 ++++++++++++++++
>  lib/rtnetlink.h          |   4 ++
>  lib/tc.c                 |  60 +++++++++++++++-------
>  lib/tc.h                 |  12 ++---
>  13 files changed, 305 insertions(+), 51 deletions(-)
>  mode change 100644 => 100755 lib/rtnetlink.h
> 
> -- 
> 2.7.4
> 
> _______________________________________________
> dev mailing list
> dev@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Simon Horman June 21, 2018, 4:27 p.m. UTC | #2
On 21 June 2018 at 18:15, Ben Pfaff <blp@ovn.org> wrote:

> Simon, I see that you have reviewed these patches.  Are you handling
> this series?
>

Hi Ben,

yes, I reviewed these patches during internal review.
I'm happy to handle the series now its in external review.


> On Thu, Jun 21, 2018 at 02:35:55PM +0100, John Hurley wrote:
> > This patchset extends OvS TC and the linux-netdev implementation to
> > support the offloading of Linux Link Aggregation devices (LAG) and their
> > slaves. TC blocks are used to provide this offload. Blocks, in TC, group
> > together a series of qdiscs. If a filter is added to one of these qdiscs
> > then it applied to all. Similarly, if a packet is matched on one of the
> > grouped qdiscs then the stats for the entire block are increased. The
> > basis of the LAG offload is that the LAG master (attached to the OvS
> > bridge) and slaves that may exist outside of OvS are all added to the
> same
> > TC block. OvS can then control the filters and collect the stats on the
> > slaves via its interaction with the LAG master.
> >
> > The TC API is extended within OvS to allow the addition of a block id to
> > ingress qdisc adds. Block ids are then assigned to each LAG master that
> is
> > attached to the OvS bridge. The linux netdev netlink socket is used to
> > monitor slave devices. If a LAG slave is found whose master is on the
> bridge
> > then it is added to the same block as its master. If the underlying
> slaves
> > belong to an offloadable device then the Linux LAG device can be
> offloaded
> > to hardware.
> >
> > John Hurley (6):
> >   tc: allow offloading of block ids
> >   netdev-provider: add class op to get block_id
> >   rtnetlink: extend parser to include kind of master and slave
> >   netdev-linux: indicate if netdev is a LAG master
> >   netdev-linux: assign LAG devs to tc blocks
> >   netdev-linux: monitor and offload LAG slaves to TC
> >
> >  lib/netdev-bsd.c         |   3 +-
> >  lib/netdev-dpdk.c        |   3 +-
> >  lib/netdev-dummy.c       |   3 +-
> >  lib/netdev-linux.c       | 128 ++++++++++++++++++++++++++++++
> ++++++++++++++---
> >  lib/netdev-provider.h    |   4 ++
> >  lib/netdev-tc-offloads.c |  82 +++++++++++++++++++++++-------
> >  lib/netdev-vport.c       |   3 +-
> >  lib/netdev.c             |  10 ++++
> >  lib/netdev.h             |   1 +
> >  lib/rtnetlink.c          |  43 ++++++++++++++++
> >  lib/rtnetlink.h          |   4 ++
> >  lib/tc.c                 |  60 +++++++++++++++-------
> >  lib/tc.h                 |  12 ++---
> >  13 files changed, 305 insertions(+), 51 deletions(-)
> >  mode change 100644 => 100755 lib/rtnetlink.h
> >
> > --
> > 2.7.4
> >
> > _______________________________________________
> > dev mailing list
> > dev@openvswitch.org
> > https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
Ben Pfaff June 21, 2018, 11:31 p.m. UTC | #3
On Thu, Jun 21, 2018 at 06:27:19PM +0200, Simon Horman wrote:
> On 21 June 2018 at 18:15, Ben Pfaff <blp@ovn.org> wrote:
> 
> > Simon, I see that you have reviewed these patches.  Are you handling
> > this series?
> >
> 
> Hi Ben,
> 
> yes, I reviewed these patches during internal review.
> I'm happy to handle the series now its in external review.

OK.

If you want a second look at any of them, please let me know what you'd
like me to look at.
Simon Horman June 25, 2018, 7:58 a.m. UTC | #4
On Thu, Jun 21, 2018 at 04:31:35PM -0700, Ben Pfaff wrote:
> On Thu, Jun 21, 2018 at 06:27:19PM +0200, Simon Horman wrote:
> > On 21 June 2018 at 18:15, Ben Pfaff <blp@ovn.org> wrote:
> > 
> > > Simon, I see that you have reviewed these patches.  Are you handling
> > > this series?
> > >
> > 
> > Hi Ben,
> > 
> > yes, I reviewed these patches during internal review.
> > I'm happy to handle the series now its in external review.
> 
> OK.
> 
> If you want a second look at any of them, please let me know what you'd
> like me to look at.

Hi Ben,

I believe the patches are clean and low risk in the sense that they should
not adversely affect any existing use-cases.  The series starts of with
some plumbing and the last patch pulls things together.

I would be grateful if you could find time to look over the last patch,
perhaps rolling back to earlier patches if you need more context. But I am
also comfortable moving forwards without your review. I'll let things sit
for a few more days to see how things progress.
Ben Pfaff June 26, 2018, 6:24 p.m. UTC | #5
On Mon, Jun 25, 2018 at 09:58:45AM +0200, Simon Horman wrote:
> On Thu, Jun 21, 2018 at 04:31:35PM -0700, Ben Pfaff wrote:
> > On Thu, Jun 21, 2018 at 06:27:19PM +0200, Simon Horman wrote:
> > > On 21 June 2018 at 18:15, Ben Pfaff <blp@ovn.org> wrote:
> > > 
> > > > Simon, I see that you have reviewed these patches.  Are you handling
> > > > this series?
> > > >
> > > 
> > > Hi Ben,
> > > 
> > > yes, I reviewed these patches during internal review.
> > > I'm happy to handle the series now its in external review.
> > 
> > OK.
> > 
> > If you want a second look at any of them, please let me know what you'd
> > like me to look at.
> 
> Hi Ben,
> 
> I believe the patches are clean and low risk in the sense that they should
> not adversely affect any existing use-cases.  The series starts of with
> some plumbing and the last patch pulls things together.
> 
> I would be grateful if you could find time to look over the last patch,
> perhaps rolling back to earlier patches if you need more context. But I am
> also comfortable moving forwards without your review. I'll let things sit
> for a few more days to see how things progress.

OK.  Thanks for letting me know.  I'm more or less on vacation this week
but I'll try to get to it soon.