From: Samudrala, Sridhar <sridhar.samudrala@intel.com>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] [next-queue v6 PATCH 5/7] i40e: Add TX and RX support over port netdev's in switchdev mode
Date: Mon, 3 Apr 2017 11:52:48 -0700 [thread overview]
Message-ID: <58E29A00.2020805@intel.com> (raw)
In-Reply-To: <CAJ3xEMiU-p5nnQSzWDYDsfam+gEK0TnAEz8uB7V7qWMm-fjH8g@mail.gmail.com>
On 3/30/2017 2:26 AM, Or Gerlitz wrote:
> On Thu, Mar 30, 2017 at 3:22 AM, Sridhar Samudrala
> <sridhar.samudrala@intel.com> wrote:
>> Any frames sent via port netdevs are sent as directed transmits to the
>> corresponding VFs.
> okay, cool
>
>> In switchdev mode, broadcasts from VFs are received by the PF and passed
>> to corresponding port representor netdev.
> not following.
>
> If a VF sends a packet and it doesn't match any HW steering rule, then
> it has to meet some default rule. Such rule can be fwd to host CPU or drop
> or something else.
>
> E.g in mlx5 currently it's fwd to CPU --> the packet is delivered to
> the HW queue
> of the corresponding VF rep is received into the host networking stack
> from there
> (the VF rep does netif_rx).
fwd to CPU as default rule is not possible with the current generation
of hw/fw.
So we would like to enable switchdev to expose the port representors and
start
adding offloads in an incremental way.
>
> In this series you are not doing any offloading, right? so 100% of the packets
> sent by VFs should meet your default rule which I assume you want to be
> fwd to host CPU (--> vf rep)
>
> Is that broadcast a special case which will remain in place also when you
> add fdb/tc offloading? why not let the HW steering configuration for all types
> of traffic be dictated by offloading some SW switching rules?
>
> FWIW - I will not be online till Tues, so will see you reply only then
>
> Or.
WARNING: multiple messages have this Message-ID (diff)
From: "Samudrala, Sridhar" <sridhar.samudrala@intel.com>
To: Or Gerlitz <gerlitz.or@gmail.com>
Cc: intel-wired-lan@lists.osuosl.org,
Linux Netdev List <netdev@vger.kernel.org>,
Alexander Duyck <alexander.h.duyck@intel.com>,
Anjali Singhai Jain <anjali.singhai@intel.com>,
Jakub Kicinski <jakub.kicinski@netronome.com>,
Jiri Pirko <jiri@resnulli.us>
Subject: Re: [next-queue v6 PATCH 5/7] i40e: Add TX and RX support over port netdev's in switchdev mode
Date: Mon, 3 Apr 2017 11:52:48 -0700 [thread overview]
Message-ID: <58E29A00.2020805@intel.com> (raw)
In-Reply-To: <CAJ3xEMiU-p5nnQSzWDYDsfam+gEK0TnAEz8uB7V7qWMm-fjH8g@mail.gmail.com>
On 3/30/2017 2:26 AM, Or Gerlitz wrote:
> On Thu, Mar 30, 2017 at 3:22 AM, Sridhar Samudrala
> <sridhar.samudrala@intel.com> wrote:
>> Any frames sent via port netdevs are sent as directed transmits to the
>> corresponding VFs.
> okay, cool
>
>> In switchdev mode, broadcasts from VFs are received by the PF and passed
>> to corresponding port representor netdev.
> not following.
>
> If a VF sends a packet and it doesn't match any HW steering rule, then
> it has to meet some default rule. Such rule can be fwd to host CPU or drop
> or something else.
>
> E.g in mlx5 currently it's fwd to CPU --> the packet is delivered to
> the HW queue
> of the corresponding VF rep is received into the host networking stack
> from there
> (the VF rep does netif_rx).
fwd to CPU as default rule is not possible with the current generation
of hw/fw.
So we would like to enable switchdev to expose the port representors and
start
adding offloads in an incremental way.
>
> In this series you are not doing any offloading, right? so 100% of the packets
> sent by VFs should meet your default rule which I assume you want to be
> fwd to host CPU (--> vf rep)
>
> Is that broadcast a special case which will remain in place also when you
> add fdb/tc offloading? why not let the HW steering configuration for all types
> of traffic be dictated by offloading some SW switching rules?
>
> FWIW - I will not be online till Tues, so will see you reply only then
>
> Or.
next prev parent reply other threads:[~2017-04-03 18:52 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-30 0:22 [Intel-wired-lan] [next-queue v6 PATCH 0/7] i40e: Add port representor and initial switchdev support Sridhar Samudrala
2017-03-30 0:22 ` Sridhar Samudrala
2017-03-30 0:22 ` [Intel-wired-lan] [next-queue v6 PATCH 1/7] i40e: Introduce devlink interface Sridhar Samudrala
2017-03-30 0:22 ` Sridhar Samudrala
2017-03-31 19:35 ` [Intel-wired-lan] " Bowers, AndrewX
2017-03-30 0:22 ` [Intel-wired-lan] [next-queue v6 PATCH 2/7] i40e: Introduce Port Representor netdevs and switchdev mode Sridhar Samudrala
2017-03-30 0:22 ` Sridhar Samudrala
2017-03-30 7:17 ` [Intel-wired-lan] " Or Gerlitz
2017-04-03 18:41 ` Samudrala, Sridhar
2017-04-04 11:58 ` Or Gerlitz
2017-04-04 11:58 ` Or Gerlitz
2017-04-04 15:29 ` [Intel-wired-lan] " Alexander Duyck
2017-04-04 15:29 ` Alexander Duyck
2017-04-05 13:41 ` Or Gerlitz
2017-04-05 13:41 ` Or Gerlitz
2017-03-30 9:17 ` Or Gerlitz
2017-03-30 9:17 ` Or Gerlitz
2017-03-31 19:35 ` [Intel-wired-lan] " Bowers, AndrewX
2017-03-30 0:22 ` [Intel-wired-lan] [next-queue v6 PATCH 3/7] i40e: Sync link state between PF/VFs and Port representor netdevs Sridhar Samudrala
2017-03-30 0:22 ` Sridhar Samudrala
2017-03-31 19:37 ` [Intel-wired-lan] " Bowers, AndrewX
2017-03-30 0:22 ` [Intel-wired-lan] [next-queue v6 PATCH 4/7] net: store port/representator id in metadata_dst Sridhar Samudrala
2017-03-30 0:22 ` Sridhar Samudrala
2017-03-31 19:42 ` [Intel-wired-lan] " Bowers, AndrewX
2017-03-30 0:22 ` [Intel-wired-lan] [next-queue v6 PATCH 5/7] i40e: Add TX and RX support over port netdev's in switchdev mode Sridhar Samudrala
2017-03-30 0:22 ` Sridhar Samudrala
2017-03-30 9:26 ` [Intel-wired-lan] " Or Gerlitz
2017-03-30 9:26 ` Or Gerlitz
2017-04-03 18:52 ` Samudrala, Sridhar [this message]
2017-04-03 18:52 ` Samudrala, Sridhar
2017-04-14 16:47 ` [Intel-wired-lan] " Alexander Duyck
2017-04-14 16:47 ` Alexander Duyck
2017-04-14 18:26 ` Samudrala, Sridhar
2017-04-14 18:26 ` Samudrala, Sridhar
2017-03-30 0:22 ` [Intel-wired-lan] [next-queue v6 PATCH 6/7] i40e: Add support for exposing switch port statistics via port netdevs Sridhar Samudrala
2017-03-30 0:22 ` Sridhar Samudrala
2017-03-31 19:39 ` [Intel-wired-lan] " Bowers, AndrewX
2017-03-30 0:22 ` [Intel-wired-lan] [next-queue v6 PATCH 7/7] i40e: Add support to get switch id and port number for " Sridhar Samudrala
2017-03-30 0:22 ` Sridhar Samudrala
2017-03-30 21:45 ` [Intel-wired-lan] " Jakub Kicinski
2017-03-30 21:45 ` Jakub Kicinski
2017-03-30 22:31 ` [Intel-wired-lan] " Alexander Duyck
2017-03-30 22:31 ` Alexander Duyck
2017-03-31 1:16 ` [Intel-wired-lan] " Jakub Kicinski
2017-03-31 1:16 ` Jakub Kicinski
2017-03-31 21:09 ` [Intel-wired-lan] " Bowers, AndrewX
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=58E29A00.2020805@intel.com \
--to=sridhar.samudrala@intel.com \
--cc=intel-wired-lan@osuosl.org \
/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.