From: roopa <roopa@cumulusnetworks•com>
To: Jiri Pirko <jiri@resnulli•us>
Cc: sfeldma@gmail•com, jhs@mojatatu•com, bcrl@kvack•org,
tgraf@suug•ch, john.fastabend@gmail•com,
stephen@networkplumber•org, vyasevic@redhat•com,
ronen.arad@intel•com, netdev@vger•kernel.org,
davem@davemloft•net, shm@cumulusnetworks•com,
gospo@cumulusnetworks•com
Subject: Re: [PATCH net-next v4 0/7] switchdev offload flags
Date: Fri, 30 Jan 2015 11:49:07 -0800 [thread overview]
Message-ID: <54CBE033.4010501@cumulusnetworks.com> (raw)
In-Reply-To: <20150130165940.GA1872@nanopsycho.orion>
On 1/30/15, 8:59 AM, Jiri Pirko wrote:
> Fri, Jan 30, 2015 at 07:40:10AM CET, roopa@cumulusnetworks•com wrote:
>> From: Roopa Prabhu <roopa@cumulusnetworks•com>
>>
>> This patch series introduces new offload flags for switchdev.
>> Kernel network subsystems can use this flag to accelerate
>> network functions by offloading to hw.
>>
>> I expect that there will be need for subsystem specific feature
>> flag in the future.
>>
>> This patch series currently only addresses bridge driver link
>> attribute offloads to hardware.
>>
>> Looking at the current state of bridge l2 offload in the kernel,
>> - flag 'self' is the way to directly manage the bridge device in hw via
>> the ndo_bridge_setlink/ndo_bridge_getlink calls
>>
>> - flag 'master' is always used to manage the in kernel bridge devices
>> via the same ndo_bridge_setlink/ndo_bridge_getlink calls
>>
>> Today these are used separately. The nic offloads use hwmode "vepa/veb" to go
>> directly to hw with the "self" flag.
>>
>> At this point i am trying not to introduce any new user facing flags/attributes.
>> In the model where we want the kernel bridging to be accelerated with
>> hardware, we very much want the bridge driver to be involved.
>>
>> In this proposal,
>> - The offload flag/bit helps switch asic drivers to indicate that they
>> accelerate the kernel networking objects/functions
>> - The user does not have to specify a new flag to do so. A bridge created with
>> switch asic ports will be accelerated if the switch driver supports it.
>> - The user can continue to directly manage l2 in nics (ixgbe) using the
>> existing hwmode/self flags
>> - It also does not stop users from using the 'self' flag to talk to the
>> switch asic driver directly
>> - Involving the bridge driver makes sure the add/del notifications to user
>> space go out after both kernel and hardware are programmed
>>
>> (To selectively offload bridge port attributes,
>> example learning in hw only etc, we can introduce offload bits for
>> per bridge port flag attribute as in my previous patch
>> https://patchwork.ozlabs.org/patch/413211/. I have not included that in this
>> series)
>>
>> v2
>> - try a different name for the offload flag/bit
>> - tries to solve the stacked netdev case by traversing the lowerdev
>> list to reach the switch port
>>
>> v3 -
>> - Tested with bond as bridge port for the stacked device case.
>> Includes a bond_fix_features change to not ignore the
>> NETIF_F_HW_NETFUNC_OFFLOAD flag
>> - Some checkpatch fixes
>>
>> v4 -
>> - rename flag to NETIF_F_HW_SWITCH_OFFLOAD
>> - add ndo_bridge_setlink/dellink handlers in bond and team drivers as
>> suggested by jiri.
>> - introduce default ndo_dflt_netdev_switch_port_bridge_setlink/dellink
>> handlers that masters can use to call offload api on lowerdevs.
>>
>> Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks•com>
>
> Having a flu and being completely unusable, I gave this patchset a quick
> peek and looks allright. I will review once I recover (Sun/Mon).
> Not sure if Dave wants to hold the patchset until then.
>
>
ok sounds good, thanks, hope you feel better soon.
next prev parent reply other threads:[~2015-01-30 19:49 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-30 6:40 [PATCH net-next v4 0/7] switchdev offload flags roopa
2015-01-30 16:59 ` Jiri Pirko
2015-01-30 19:49 ` roopa [this message]
2015-02-02 7:16 ` David Miller
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=54CBE033.4010501@cumulusnetworks.com \
--to=roopa@cumulusnetworks$(echo .)com \
--cc=bcrl@kvack$(echo .)org \
--cc=davem@davemloft$(echo .)net \
--cc=gospo@cumulusnetworks$(echo .)com \
--cc=jhs@mojatatu$(echo .)com \
--cc=jiri@resnulli$(echo .)us \
--cc=john.fastabend@gmail$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=ronen.arad@intel$(echo .)com \
--cc=sfeldma@gmail$(echo .)com \
--cc=shm@cumulusnetworks$(echo .)com \
--cc=stephen@networkplumber$(echo .)org \
--cc=tgraf@suug$(echo .)ch \
--cc=vyasevic@redhat$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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