DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Zhang, Roy Fan" <roy.fan.zhang@intel.com>
To: Panu Matilainen <pmatilai@redhat.com>, dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH 1/4] lib/librte_port: add PCAP file support to source port
Date: Fri, 29 Jan 2016 15:10:42 +0000	[thread overview]
Message-ID: <56AB80F2.2070609@intel.com> (raw)
In-Reply-To: <56AA0161.30308@redhat.com>

Hi Panu,

Thank you for the careful review and comments.

On 28/01/2016 11:54, Panu Matilainen wrote:
> On 01/27/2016 07:39 PM, Fan Zhang wrote:
>> Originally, source ports in librte_port is an input port used as packet
>> generator. Similar to Linux kernel /dev/zero character device, it
>> generates null packets. This patch adds optional PCAP file support to
>> source port: instead of sending NULL packets, the source port generates
>> packets copied from a PCAP file. To increase the performance, the 
>> packets
>> in the file are loaded to memory initially, and copied to mbufs in 
>> circular
>> manner. Users can enable or disable this feature by setting
>> CONFIG_RTE_PORT_PCAP compiler option "y" or "n".
>>
>> Signed-off-by: Fan Zhang <roy.fan.zhang@intel.com>
>> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
>> ---
>>   config/common_bsdapp                   |   1 +
>>   config/common_linuxapp                 |   1 +
>>   lib/librte_port/Makefile               |   4 +
>>   lib/librte_port/rte_port_source_sink.c | 190 
>> +++++++++++++++++++++++++++++++++
>>   lib/librte_port/rte_port_source_sink.h |   7 ++
>>   mk/rte.app.mk                          |   1 +
>>   6 files changed, 204 insertions(+)
>>
> [...]
>> +#ifdef RTE_PORT_PCAP
>> +
>> +/**
>> + * Load PCAP file, allocate and copy packets in the file to memory
>> + *
>> + * @param p
>> + *   Parameters for source port
>> + * @param port
>> + *   Handle to source port
>> + * @param socket_id
>> + *   Socket id where the memory is created
>> + * @return
>> + *   0 on SUCCESS
>> + *   error code otherwise
>> + */
>> +static int
>> +pcap_source_load(struct rte_port_source_params *p,
>> +        struct rte_port_source *port,
>> +        int socket_id)
>> +{
> [...]
>> +#else
>> +static int
>> +pcap_source_load(__rte_unused struct rte_port_source_params *p,
>> +        struct rte_port_source *port,
>> +        __rte_unused int socket_id)
>> +{
>> +    port->pkt_buff = NULL;
>> +    port->pkt_len = NULL;
>> +    port->pkts = NULL;
>> +    port->pkt_index = 0;
>> +
>> +    return 0;
>> +}
>> +#endif
>
> Same as in patch 3/4, shouldn't this return -ENOTSUP when pcap support 
> is not built in, instead of success?

Thank you for the suggestion. I will make the change in V2.

> [...]
>
>> diff --git a/lib/librte_port/rte_port_source_sink.h 
>> b/lib/librte_port/rte_port_source_sink.h
>> index 0f9be79..6f39bec 100644
>> --- a/lib/librte_port/rte_port_source_sink.h
>> +++ b/lib/librte_port/rte_port_source_sink.h
>> @@ -53,6 +53,13 @@ extern "C" {
>>   struct rte_port_source_params {
>>       /** Pre-initialized buffer pool */
>>       struct rte_mempool *mempool;
>> +    /** The full path of the pcap file to read packets from */
>> +    char *file_name;
>> +    /** The number of bytes to be read from each packet in the
>> +     *  pcap file. If this value is 0, the whole packet is read;
>> +     *  if it is bigger than packet size, the generated packets
>> +     *  will contain the whole packet */
>> +    uint32_t n_bytes_per_pkt;
>>   };
>
> This is a likely ABI-break. It "only" appends to the struct, which 
> might in some cases be okay but only when there's no sensible use for 
> the struct within arrays or embedded in structs. The ip_pipeline 
> example for example embeds struct rte_port_source_params within 
> another struct which is could be thought of as an indication that 
> other applications might be doing this as well.
>
> An ABI break for librte_port has not been announced for 2.3 so you'd 
> need to announce the intent to do so in 2.4 now, and then either wait 
> till post 2.3 or wrap this in CONFIG_RTE_NEXT_ABI.
>     - Panu -

Before Submitting the patch I have run validate-abi script, the 
validation results showed "compatible" on all libraries.

Also, the patch's added line in the rte_port_source_sink.c was ensured 
that, if the CONFIG_RTE_PORT_PCAP compiler option is set to "n" (by 
default), the added read-only elements in the new rte_source_params 
structure won't be touched.
CONFIG_RTE_PORT_PCAP compiler option lies in config/comm_bsdapp and 
config/com_linuxapp, and is freshly added in this patch.

If an application is built on top of latest release version of 
rte_port_source_sink library, it shall work fine with the new library if 
the new CONFIG_RTE_PORT_PCAP opition is left the default "n".
ip_pipeline example works fine this way.

I hope this changes your mind on breaking the ABI.

Best regards,
Fan

  reply	other threads:[~2016-01-29 15:10 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-27 17:39 [dpdk-dev] [PATCH 0/4] Add PCAP support to source and sink port Fan Zhang
2016-01-27 17:39 ` [dpdk-dev] [PATCH 1/4] lib/librte_port: add PCAP file support to source port Fan Zhang
2016-01-28 11:54   ` Panu Matilainen
2016-01-29 15:10     ` Zhang, Roy Fan [this message]
2016-01-27 17:39 ` [dpdk-dev] [PATCH 2/4] examples/ip_pipeline: add PCAP file support Fan Zhang
2016-01-27 17:39 ` [dpdk-dev] [PATCH 3/4] lib/librte_port: add packet dumping to PCAP file support in sink port Fan Zhang
2016-01-28 11:43   ` Panu Matilainen
2016-01-29 15:34     ` Zhang, Roy Fan
2016-01-27 17:39 ` [dpdk-dev] [PATCH 4/4] examples/ip_pipeline: add packets dumping to PCAP file support Fan Zhang

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=56AB80F2.2070609@intel.com \
    --to=roy.fan.zhang@intel.com \
    --cc=dev@dpdk.org \
    --cc=pmatilai@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 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).