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.
next prev parent reply other threads:[~2017-04-03 18:52 UTC|newest]
Thread overview: 27+ 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 ` [Intel-wired-lan] [next-queue v6 PATCH 1/7] i40e: Introduce devlink interface Sridhar Samudrala
2017-03-31 19:35 ` 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 7:17 ` Or Gerlitz
2017-04-03 18:41 ` Samudrala, Sridhar
2017-04-04 11:58 ` Or Gerlitz
2017-04-04 15:29 ` Alexander Duyck
2017-04-05 13:41 ` Or Gerlitz
2017-03-30 9:17 ` Or Gerlitz
2017-03-31 19:35 ` 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-31 19:37 ` 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-31 19:42 ` 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 9:26 ` Or Gerlitz
2017-04-03 18:52 ` Samudrala, Sridhar [this message]
2017-04-14 16:47 ` Alexander Duyck
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-31 19:39 ` 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 21:45 ` Jakub Kicinski
2017-03-30 22:31 ` Alexander Duyck
2017-03-31 1:16 ` Jakub Kicinski
2017-03-31 21:09 ` 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox