From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
To: Michal Miroslaw <mirq-linux@rere.qmqm.pl>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH 06/13] null: fake PMD capabilities
Date: Tue, 13 Dec 2016 17:12:11 +0000 [thread overview]
Message-ID: <2601191342CEEE43887BDE71AB9772583F0E754B@irsmsx105.ger.corp.intel.com> (raw)
In-Reply-To: <20161213145742.hxvtr63anhy7ai33@rere.qmqm.pl>
> -----Original Message-----
> From: Michal Miroslaw [mailto:mirq-linux@rere.qmqm.pl]
> Sent: Tuesday, December 13, 2016 2:58 PM
> To: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 06/13] null: fake PMD capabilities
>
> On Tue, Dec 13, 2016 at 02:37:34PM +0000, Ananyev, Konstantin wrote:
> >
> >
> > > -----Original Message-----
> > > From: Michal Miroslaw [mailto:mirq-linux@rere.qmqm.pl]
> > > Sent: Tuesday, December 13, 2016 2:27 PM
> > > To: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> > > Cc: dev@dpdk.org
> > > Subject: Re: [dpdk-dev] [PATCH 06/13] null: fake PMD capabilities
> > >
> > > On Tue, Dec 13, 2016 at 10:48:32AM +0000, Ananyev, Konstantin wrote:
> > > > > -----Original Message-----
> > > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Michal Miroslaw
> > > > > Sent: Tuesday, December 13, 2016 1:08 AM
> > > > > To: dev@dpdk.org
> > > > > Subject: [dpdk-dev] [PATCH 06/13] null: fake PMD capabilities
> > > > >
> > > > > From: Paweł Małachowski <pawel.malachowski@atendesoftware.pl>
> > > > >
> > > > > Thanks to that change we can use Null PMD for testing purposes.
> > > > >
> > > > > Signed-off-by: Michał Mirosław <michal.miroslaw@atendesoftware.pl>
> > > > > ---
> > > > > drivers/net/null/rte_eth_null.c | 13 ++++++++++++-
> > > > > 1 file changed, 12 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/net/null/rte_eth_null.c b/drivers/net/null/rte_eth_null.c
> > > > > index 836d982..f32ba2a 100644
> > > > > --- a/drivers/net/null/rte_eth_null.c
> > > > > +++ b/drivers/net/null/rte_eth_null.c
> > > > > @@ -284,6 +284,9 @@ eth_tx_queue_setup(struct rte_eth_dev *dev, uint16_t tx_queue_id,
> > > > > return 0;
> > > > > }
> > > > >
> > > > > +static void
> > > > > +eth_dev_void_ok(struct rte_eth_dev *dev __rte_unused) { return; }
> > > > > +
> > > > >
> > > > > static void
> > > > > eth_dev_info(struct rte_eth_dev *dev,
> > > > > @@ -304,6 +307,9 @@ eth_dev_info(struct rte_eth_dev *dev,
> > > > > dev_info->pci_dev = NULL;
> > > > > dev_info->reta_size = internals->reta_size;
> > > > > dev_info->flow_type_rss_offloads = internals->flow_type_rss_offloads;
> > > > > + /* We hereby declare we can RX-offload VLAN-s out of thin air and update checksums and VLANs before sinking
> packets in
> > > > > /dev/null */
> > > > > + dev_info->rx_offload_capa = DEV_RX_OFFLOAD_VLAN_STRIP;
> > > > > + dev_info->tx_offload_capa = DEV_TX_OFFLOAD_VLAN_INSERT | DEV_TX_OFFLOAD_IPV4_CKSUM;
> > > >
> > > > Hmm, how could it be supported if all that null PMD does on TX - just free the packets?
> > > > Same question for RX.
> > >
> > > You could imagine, that before dropping the packet you insert the tag
> > > and calculate the checksum. The observed effect will be the same.
> > >
> > > On RX this always indicates lack of VLAN tag. So whether the offload
> > > is enabled or not it doesn't matter.
> >
> > Of course user can imagine whatever he likes, but what the point to advertise these capabilities,
> > when the PMD clearly doesn't have them?
> > Again, why these particular ones?
>
> Hmm. I guess we can expand the set. Those were the ones we actually use
> (depend on) for testing our code.
>
> This allows to use null PMD for testing in place of real network interface
> with those offloads.
As I can see on TX null pmd would just drop the packets, right?
So the only thing you might check, as I understand, did upper layer code
setup ol_flags and other mbuf fields properly depending on advertised capabilities
(probably via sme special tx_callback installed or so).
Is that correct?
That's ok, I suppose, but if tomorrow you (or someone else) would like to test
with different RX/TX offloads?
Shouldn't be advertised offload capabilities be configurable at device creation/attach time
somehow?
Or at least just advertise all possible ones then?
Konstantin
>This patch is to keep users from having to place if's
> around their code just to support test scenarios with null PMD.
>
> Best Regards,
> Michał Mirosław
next prev parent reply other threads:[~2016-12-13 17:12 UTC|newest]
Thread overview: 95+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-13 1:08 [dpdk-dev] [PATCH 00/13] Fixes and tweaks Michał Mirosław
2016-12-13 1:08 ` [dpdk-dev] [PATCH 01/13] EAL: count nr_overcommit_hugepages as available Michał Mirosław
[not found] ` <20161213010852.862C4376C@dpdk.org>
2016-12-13 1:28 ` [dpdk-dev] [PATCH v2 " Michał Mirosław
2017-04-30 15:53 ` Thomas Monjalon
2017-05-04 18:43 ` Michał Mirosław
2019-01-17 17:18 ` Ferruh Yigit
2016-12-13 1:08 ` [dpdk-dev] [PATCH 02/13] mbuf: rte_pktmbuf_free_bulk() Michał Mirosław
2016-12-13 21:41 ` Stephen Hemminger
2016-12-14 2:09 ` Michał Mirosław
2016-12-13 1:08 ` [dpdk-dev] [PATCH 03/13] rte_ether: set PKT_RX_VLAN_STRIPPED in rte_vlan_strip() Michał Mirosław
2017-01-30 9:54 ` Thomas Monjalon
2017-02-09 15:56 ` Olivier MATZ
2017-04-30 15:58 ` Thomas Monjalon
2017-05-04 7:30 ` Olivier MATZ
2017-05-04 22:36 ` [dpdk-dev] [PATCH v2] net: fix stripped VLAN flag for offload emulation Thomas Monjalon
2017-05-05 10:02 ` Olivier Matz
2017-05-05 14:00 ` [dpdk-dev] [dpdk-stable] " Thomas Monjalon
2016-12-13 1:08 ` [dpdk-dev] [PATCH 06/13] null: fake PMD capabilities Michał Mirosław
[not found] ` <20161213010913.34C8B5597@dpdk.org>
2016-12-13 1:28 ` [dpdk-dev] [PATCH v2 " Michał Mirosław
2016-12-13 1:35 ` [dpdk-dev] [-- " Michał Mirosław
2016-12-13 10:48 ` [dpdk-dev] [PATCH " Ananyev, Konstantin
2016-12-13 14:26 ` Michal Miroslaw
2016-12-13 14:37 ` Ananyev, Konstantin
2016-12-13 14:57 ` Michal Miroslaw
2016-12-13 17:12 ` Ananyev, Konstantin [this message]
2016-12-13 17:31 ` Ferruh Yigit
2016-12-14 19:16 ` [dpdk-dev] [PATCH v4] " Michał Mirosław
2017-01-09 12:07 ` Ferruh Yigit
2017-01-11 10:14 ` Michał Mirosław
2017-01-11 12:23 ` Ferruh Yigit
2016-12-13 1:08 ` [dpdk-dev] [PATCH 04/13] acl: allow zero verdict Michał Mirosław
2016-12-13 10:36 ` Ananyev, Konstantin
2016-12-13 13:54 ` Michal Miroslaw
2016-12-13 14:14 ` Ananyev, Konstantin
2016-12-13 14:53 ` Michal Miroslaw
2016-12-13 15:13 ` Ananyev, Konstantin
2016-12-13 16:14 ` Michal Miroslaw
2016-12-13 16:43 ` Michal Miroslaw
2016-12-13 17:27 ` Ananyev, Konstantin
2016-12-13 18:02 ` Michal Miroslaw
2016-12-13 21:55 ` Ananyev, Konstantin
2016-12-14 2:11 ` Michal Miroslaw
2016-12-14 12:16 ` Ananyev, Konstantin
2016-12-13 1:08 ` [dpdk-dev] [PATCH 05/13] acl: fix acl_flow_data comments Michał Mirosław
2016-12-13 10:43 ` Ananyev, Konstantin
2017-01-30 10:15 ` Thomas Monjalon
2016-12-13 1:08 ` [dpdk-dev] [PATCH 08/13] PMD/af_packet: guard against buffer overruns in RX path Michał Mirosław
[not found] ` <20161213010918.F1B095684@dpdk.org>
2016-12-13 1:28 ` [dpdk-dev] [PATCH v2 " Michał Mirosław
2016-12-13 16:05 ` John W. Linville
2016-12-16 10:32 ` Ferruh Yigit
2017-01-18 11:48 ` [dpdk-dev] [PATCH " Ferruh Yigit
2017-01-18 19:22 ` Michał Mirosław
2016-12-13 1:08 ` [dpdk-dev] [PATCH 07/13] pcap: fix timestamps in output pcap file Michał Mirosław
2016-12-14 17:45 ` Ferruh Yigit
2016-12-16 10:06 ` Ferruh Yigit
2016-12-13 1:08 ` [dpdk-dev] [PATCH 09/13] PMD/af_packet: guard against buffer overruns in TX path Michał Mirosław
[not found] ` <20161213010927.9B12CFA30@dpdk.org>
2016-12-13 1:28 ` [dpdk-dev] [PATCH v2 " Michał Mirosław
2016-12-13 16:06 ` John W. Linville
2016-12-16 10:32 ` Ferruh Yigit
2016-12-13 1:08 ` [dpdk-dev] [PATCH 10/13] KNI: provided netif name's source is user-space Michał Mirosław
2016-12-14 17:06 ` Ferruh Yigit
2016-12-14 17:19 ` Michał Mirosław
2016-12-14 17:35 ` Ferruh Yigit
2016-12-14 17:35 ` Ferruh Yigit
2017-01-29 21:50 ` Thomas Monjalon
2016-12-13 1:08 ` [dpdk-dev] [PATCH 11/13] KNI: guard against unterminated dev_info.name leading to BUG in alloc_netdev() Michał Mirosław
2016-12-14 17:33 ` Ferruh Yigit
2016-12-14 17:37 ` Michał Mirosław
2016-12-14 17:48 ` Ferruh Yigit
2017-01-29 21:53 ` Thomas Monjalon
2016-12-13 1:08 ` [dpdk-dev] [PATCH 13/13] i40e: improve message grepability Michał Mirosław
2016-12-28 3:51 ` Wu, Jingjing
2017-01-09 12:02 ` Bruce Richardson
2017-01-09 13:18 ` Thomas Monjalon
2017-01-09 17:25 ` Stephen Hemminger
2017-01-09 14:11 ` Ferruh Yigit
2017-01-11 9:49 ` [dpdk-dev] [PATCH] " Michał Mirosław
2017-01-11 16:05 ` Ferruh Yigit
2017-01-11 17:13 ` [dpdk-dev] [PATCH v3 1/1] " Michał Mirosław
2017-01-11 17:50 ` Ferruh Yigit
2017-01-11 17:52 ` Ferruh Yigit
2016-12-13 1:08 ` [dpdk-dev] [PATCH 12/13] i40e: return -errno when intr setup fails Michał Mirosław
2016-12-22 15:45 ` Ferruh Yigit
2016-12-23 1:55 ` Michał Mirosław
2016-12-28 3:47 ` Wu, Jingjing
2017-01-11 16:09 ` Ferruh Yigit
2016-12-14 17:23 ` [dpdk-dev] [PATCH v2] acl: allow zero verdict Michał Mirosław
2016-12-19 18:54 ` Ananyev, Konstantin
2016-12-14 17:23 ` [dpdk-dev] [PATCH] acl: remove invalid test Michał Mirosław
2016-12-19 18:48 ` Ananyev, Konstantin
2016-12-23 1:47 ` Michal Miroslaw
2016-12-23 9:36 ` Ananyev, Konstantin
2017-01-17 15:24 ` Thomas Monjalon
2017-01-18 9:51 ` Ananyev, Konstantin
2017-01-18 19:21 ` Michal Miroslaw
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=2601191342CEEE43887BDE71AB9772583F0E754B@irsmsx105.ger.corp.intel.com \
--to=konstantin.ananyev@intel.com \
--cc=dev@dpdk.org \
--cc=mirq-linux@rere.qmqm.pl \
/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).