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.com \
--cc=bcrl@kvack.org \
--cc=davem@davemloft.net \
--cc=gospo@cumulusnetworks.com \
--cc=jhs@mojatatu.com \
--cc=jiri@resnulli.us \
--cc=john.fastabend@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=ronen.arad@intel.com \
--cc=sfeldma@gmail.com \
--cc=shm@cumulusnetworks.com \
--cc=stephen@networkplumber.org \
--cc=tgraf@suug.ch \
--cc=vyasevic@redhat.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.