From: Mohammad Abdul Awal <mohammad.abdul.awal@intel.com>
To: Alex Rosenbaum <rosenbaumalex@gmail.com>,
Declan Doherty <declan.doherty@intel.com>
Cc: dev <dev@dpdk.org>, Remy Horton <remy.horton@intel.com>,
Rony Efraim <ronye@mellanox.com>,
Alejandro Lucero <alejandro.lucero@netronome.com>
Subject: Re: [dpdk-dev] [RFC 0/5] Port Representor for control and monitoring of VF devices
Date: Fri, 22 Dec 2017 14:31:25 +0000 [thread overview]
Message-ID: <c15e9450-19f6-838c-c97b-ee9670dff4cd@intel.com> (raw)
In-Reply-To: <CAFgAxU87NEHyNX0OsEh3G2GVuU_4nv2zNTO3c=ryow4Xxm7qeQ@mail.gmail.com>
Hi ALex,
On 21/12/2017 14:51, Alex Rosenbaum wrote:
> Declan, Mohammad,
>
> The submission [1] of steering action between switch ports clearly
> requires a switch model in DPDK.
> The Port Representor based on a virtual PMD broker on NIC ops
> (rte_dev_ops) does not provide the required functionality. Using NIC
> terminology and not Switch API's will lead to a dead-end. Moreover, it
> does not fit the Kernel design. We need to be careful from this ending
> up as two different deployment models for users, which is very bad.
> There was a long discussion about this in netdev ML [2], including the
> VEPA mode support.
>
> As described in the links Alejandro referenced earlier, each of the
> switch ports should be a real PMD, and switch operations should be
> applied on these PMD ports.
> This includes the steering redirection of traffic between switch ports
> [1], port ACL's to block/allow traffic, VST/VGT modes and anti
> spoofing, link trust mode [3] for promiscuous configuration, mirroring
> of switch port traffic, and Tx and Rx of switch port traffic to/from
> VF's port.
I agree that we need a switch_domain parameter. At the moment we do not
have APIs implemented for all the switch operations you have mentioned
above. So, we are planning separate RFC with switch _domain and related
APIs.
>
> More over, building this as real PMD ports of a switch device removes
> the need to add a new broker framework all together.
> Each vendor just needs to map additional PMD ports during the probing
> stage.
That is very much possible as well. If we agree to probe all the ports
during the initialization phase, we can have all the representors ready
without any interaction from application and broker. On the other hand,
we may require a broker structure to enable hotplug support.
> By adding a switchdev_id we can define these are ports
> associated to the same switching device, and can allow new port and
> inter-port actions.
>
> [1] http://dpdk.org/dev/patchwork/patch/32550/
> [2] https://www.spinics.net/lists/netdev/msg467375.html
> [2] https://www.systutorials.com/docs/linux/man/8-ip-link/
>
> Alex
Regards,
Awal.
next prev parent reply other threads:[~2017-12-22 14:31 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-07 8:35 Mohammad Abdul Awal
2017-09-07 8:35 ` [dpdk-dev] [RFC 1/5] Implemented port representor broker infrastructure, created BDF to port function Mohammad Abdul Awal
2017-09-07 8:35 ` [dpdk-dev] [RFC 2/5] added --enable-representor command line argument in EAL to load representor broker infrastructure Mohammad Abdul Awal
2017-09-07 8:35 ` [dpdk-dev] [RFC 3/5] Implement port representor PMD Mohammad Abdul Awal
2017-09-07 8:35 ` [dpdk-dev] [RFC 4/5] Enable port representor PMD and broker for fortville PMD driver Mohammad Abdul Awal
2017-09-07 8:35 ` [dpdk-dev] [RFC 5/5] Enable port representor PMD and broker for ixgbe " Mohammad Abdul Awal
2017-09-07 10:01 ` [dpdk-dev] [RFC 0/5] Port Representor for control and monitoring of VF devices Alejandro Lucero
2017-09-07 13:13 ` Declan Doherty
2017-09-08 13:59 ` Alejandro Lucero
2017-12-21 14:51 ` Alex Rosenbaum
2017-12-22 14:31 ` Mohammad Abdul Awal [this message]
2017-12-22 22:33 ` Alex Rosenbaum
2017-12-27 9:40 ` Mohammad Abdul Awal
2017-12-27 15:50 ` Alex Rosenbaum
2018-01-02 15:19 ` Mohammad Abdul Awal
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=c15e9450-19f6-838c-c97b-ee9670dff4cd@intel.com \
--to=mohammad.abdul.awal@intel.com \
--cc=alejandro.lucero@netronome.com \
--cc=declan.doherty@intel.com \
--cc=dev@dpdk.org \
--cc=remy.horton@intel.com \
--cc=ronye@mellanox.com \
--cc=rosenbaumalex@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).