DPDK patches and discussions
 help / color / mirror / Atom feed
From: Ferruh Yigit <ferruh.yigit@intel.com>
To: "Van Haaren, Harry" <harry.van.haaren@intel.com>,
	"Lu, Wenzhuo" <wenzhuo.lu@intel.com>,
	"Wu, Jingjing" <jingjing.wu@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	Shahaf Shuler <shahafs@mellanox.com>,
	Yongseok Koh <yskoh@mellanox.com>
Subject: Re: [dpdk-dev] [PATCH v3] app/testpmd: print Rx/Tx offload values
Date: Tue, 13 Mar 2018 10:21:22 +0000	[thread overview]
Message-ID: <2f6f9a5e-2010-605e-5d4c-60135bd03082@intel.com> (raw)
In-Reply-To: <E923DB57A917B54B9182A2E928D00FA65E0006F6@IRSMSX102.ger.corp.intel.com>

On 3/13/2018 9:24 AM, Van Haaren, Harry wrote:
>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ferruh Yigit
>> Sent: Monday, March 12, 2018 5:53 PM
>> To: Lu, Wenzhuo <wenzhuo.lu@intel.com>; Wu, Jingjing <jingjing.wu@intel.com>
>> Cc: dev@dpdk.org; Yigit, Ferruh <ferruh.yigit@intel.com>; Shahaf Shuler
>> <shahafs@mellanox.com>; Yongseok Koh <yskoh@mellanox.com>
>> Subject: [dpdk-dev] [PATCH v3] app/testpmd: print Rx/Tx offload values
>>
>> Which per port offloads are enabled is not clear. Printing offloads
>> values at forwarding start.
>>
>> CRC strip offload value was printed in more verbose manner, it is
>> removed since Rx/Tx offload values covers it and printing only CRC one
>> can cause confusion.
>>
>> Hexadecimal offloads values are not very user friendly but preferred to
>> not create to much noise during forwarding start.
> 
> 
> Hmmm - I'm thinking is there a better method to reduce verbosity, but keep
> user friendliness?
> 
> Can the dynamic logs be used? By default, just print the hex mask, but with
> --log-level="pmd.net.*.offload_flags" we print the list, itemized?
> 
> crc strip .......... 1
> vlan strip ......... 1
> udp checksum ....... 0

As Yongseok mentioned 'show port cap all' prints the offload capabilities in a
more user friendly way [1] [2]. This patch adds a summary config log after
"start" command, I think it is good to keep it brief.

Related to the "pmd.net.*.offload_flags" suggestion, we are currently using log
types to select components, it can be interesting to use feature based log
types, ethdev may register them and PMDs can use it.


[1]
************ Port 0 supported offload features: ************
VLAN stripped:                 off
Double VLANs stripped:         off
RX IPv4 checksum:              off
RX UDP checksum:               off
RX TCP checksum:               off
RX Outer IPv4 checksum:               off
VLAN insert:                   off
Double VLANs insert:           off
TX IPv4 checksum:              off
TX UDP checksum:               off
TX TCP checksum:               off
TX SCTP checksum:              off
TX Outer IPv4 checksum:        off
TX TCP segmentation:           off
TSO for VXLAN tunnel packet:   off
TSO for GRE tunnel packet:     off
TSO for IPIP tunnel packet:    off
TSO for GENEVE tunnel packet:  off

[2]
This command needs a volunteer to add missing offloading types.

> 
> 
> I'm not sure what the exact string should be - testpmd specific or DPDK wide at the PMD level?
> 

  reply	other threads:[~2018-03-13 10:21 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-06 16:28 [dpdk-dev] [PATCH] " Ferruh Yigit
2018-03-07 21:36 ` Yongseok Koh
2018-03-09 18:27   ` Ferruh Yigit
2018-03-12 14:59 ` Ferruh Yigit
2018-03-12 15:05 ` [dpdk-dev] [PATCH v2] " Ferruh Yigit
2018-03-12 17:26   ` Yongseok Koh
2018-03-12 17:46     ` Ferruh Yigit
2018-03-12 17:53   ` [dpdk-dev] [PATCH v3] " Ferruh Yigit
2018-03-13  9:24     ` Van Haaren, Harry
2018-03-13 10:21       ` Ferruh Yigit [this message]
2018-03-13 11:06         ` Van Haaren, Harry
2018-04-22 23:02     ` Thomas Monjalon

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=2f6f9a5e-2010-605e-5d4c-60135bd03082@intel.com \
    --to=ferruh.yigit@intel.com \
    --cc=dev@dpdk.org \
    --cc=harry.van.haaren@intel.com \
    --cc=jingjing.wu@intel.com \
    --cc=shahafs@mellanox.com \
    --cc=wenzhuo.lu@intel.com \
    --cc=yskoh@mellanox.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).