diff mbox

[dpdk-dev] PATCH] mbuf: rte_pktmbuf_dump: don't add 0x when using %p in format strings

Message ID 20160620124435.23d43f28@miho (mailing list archive)
State Accepted, archived
Delegated to: Thomas Monjalon
Headers

Commit Message

Simon Kagstrom June 20, 2016, 10:44 a.m. UTC 
  I.e., avoid dump messages with double 0x0x, e.g.,

  dump mbuf at 0x0x7fac7b17c800, phys=17b17c880, buf_len=2176
    pkt_len=2064, ol_flags=0, nb_segs=1, in_port=255
    segment at 0x0x7fac7b17c800, data=0x0x7fac7b17c8f0, data_len=2064

Signed-off-by: Simon Kagstrom <simon.kagstrom@netinsight.net>
---
 lib/librte_mbuf/rte_mbuf.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Comments

Stephen Hemminger June 20, 2016, 4:19 p.m. UTC | #1 
On Mon, 20 Jun 2016 12:44:35 +0200
Simon Kagstrom <simon.kagstrom@netinsight.net> wrote:

> I.e., avoid dump messages with double 0x0x, e.g.,
> 
>   dump mbuf at 0x0x7fac7b17c800, phys=17b17c880, buf_len=2176
>     pkt_len=2064, ol_flags=0, nb_segs=1, in_port=255
>     segment at 0x0x7fac7b17c800, data=0x0x7fac7b17c8f0, data_len=2064
> 
> Signed-off-by: Simon Kagstrom <simon.kagstrom@netinsight.net>

Agreed. Many other places have same glitch.

$ git grep '0x%p'
drivers/net/vmxnet3/vmxnet3_rxtx.c:                "RXQ: cmd0 base : 0x%p cmd1 base : 0x%p comp ring base : 0x%p.",
drivers/net/vmxnet3/vmxnet3_rxtx.c:     PMD_TX_LOG(DEBUG, "TXQ: cmd base : 0x%p comp ring base : 0x%p data ring base : 0x%p.",
lib/librte_eal/linuxapp/kni/ethtool/ixgbe/ixgbe_ethtool.c:      printk(KERN_DEBUG "ixgbe_get_regs_2 0x%p\n", hw->hw_addr);
lib/librte_eal/linuxapp/kni/kni_misc.c: KNI_PRINT("tx_phys:      0x%016llx, tx_q addr:      0x%p\n",
lib/librte_eal/linuxapp/kni/kni_misc.c: KNI_PRINT("rx_phys:      0x%016llx, rx_q addr:      0x%p\n",
lib/librte_eal/linuxapp/kni/kni_misc.c: KNI_PRINT("alloc_phys:   0x%016llx, alloc_q addr:   0x%p\n",
lib/librte_eal/linuxapp/kni/kni_misc.c: KNI_PRINT("free_phys:    0x%016llx, free_q addr:    0x%p\n",
lib/librte_eal/linuxapp/kni/kni_misc.c: KNI_PRINT("req_phys:     0x%016llx, req_q addr:     0x%p\n",
lib/librte_eal/linuxapp/kni/kni_misc.c: KNI_PRINT("resp_phys:    0x%016llx, resp_q addr:    0x%p\n",
lib/librte_eal/linuxapp/kni/kni_misc.c: KNI_PRINT("mbuf_phys:    0x%016llx, mbuf_kva:       0x%p\n",
lib/librte_eal/linuxapp/kni/kni_misc.c: KNI_PRINT("mbuf_va:      0x%p\n", dev_info.mbuf_va);
lib/librte_eal/linuxapp/kni/kni_misc.c:                 KNI_DBG("PCI found: pci=0x%p, lad_dev=0x%p\n",
lib/librte_mbuf/rte_mbuf.c:     fprintf(f, "dump mbuf at 0x%p, phys=%"PRIx64", buf_len=%u\n",
lib/librte_mbuf/rte_mbuf.c:             fprintf(f, "  segment at 0x%p, data=0x%p, data_len=%u\n",
Ferruh Yigit June 21, 2016, 1:11 p.m. UTC | #2 
On 6/20/2016 5:19 PM, Stephen Hemminger wrote:
> On Mon, 20 Jun 2016 12:44:35 +0200
> Simon Kagstrom <simon.kagstrom@netinsight.net> wrote:
> 
>> I.e., avoid dump messages with double 0x0x, e.g.,
>>
>>   dump mbuf at 0x0x7fac7b17c800, phys=17b17c880, buf_len=2176
>>     pkt_len=2064, ol_flags=0, nb_segs=1, in_port=255
>>     segment at 0x0x7fac7b17c800, data=0x0x7fac7b17c8f0, data_len=2064
>>
>> Signed-off-by: Simon Kagstrom <simon.kagstrom@netinsight.net>
> 
> Agreed. Many other places have same glitch.
> 

Hi Simon,

Are you planning to extend your patch to fix all, or I can send a patch
for kni and vmxnet3?

Thanks,
ferruh
Simon Kagstrom June 22, 2016, 7:08 a.m. UTC | #3 
On 2016-06-21 15:11, Ferruh Yigit wrote:
> On 6/20/2016 5:19 PM, Stephen Hemminger wrote:
>> On Mon, 20 Jun 2016 12:44:35 +0200
>> Simon Kagstrom <simon.kagstrom@netinsight.net> wrote:
>>
>>> I.e., avoid dump messages with double 0x0x, e.g.,
>>>
>>>   dump mbuf at 0x0x7fac7b17c800, phys=17b17c880, buf_len=2176
>>>     pkt_len=2064, ol_flags=0, nb_segs=1, in_port=255
>>>     segment at 0x0x7fac7b17c800, data=0x0x7fac7b17c8f0, data_len=2064
>>>
>>> Signed-off-by: Simon Kagstrom <simon.kagstrom@netinsight.net>
>>
>> Agreed. Many other places have same glitch.
> 
> Are you planning to extend your patch to fix all, or I can send a patch
> for kni and vmxnet3?

I wasn't planning on that (this is something I just stumbled upon), so
please go ahead!

// Simon
Ferruh Yigit June 23, 2016, 10:58 a.m. UTC | #4 
On 6/22/2016 8:08 AM, Simon Kågström wrote:
> On 2016-06-21 15:11, Ferruh Yigit wrote:
>> On 6/20/2016 5:19 PM, Stephen Hemminger wrote:
>>> On Mon, 20 Jun 2016 12:44:35 +0200
>>> Simon Kagstrom <simon.kagstrom@netinsight.net> wrote:
>>>
>>>> I.e., avoid dump messages with double 0x0x, e.g.,
>>>>
>>>>   dump mbuf at 0x0x7fac7b17c800, phys=17b17c880, buf_len=2176
>>>>     pkt_len=2064, ol_flags=0, nb_segs=1, in_port=255
>>>>     segment at 0x0x7fac7b17c800, data=0x0x7fac7b17c8f0, data_len=2064
>>>>
>>>> Signed-off-by: Simon Kagstrom <simon.kagstrom@netinsight.net>
>>>
>>> Agreed. Many other places have same glitch.
>>
>> Are you planning to extend your patch to fix all, or I can send a patch
>> for kni and vmxnet3?
> 
> I wasn't planning on that (this is something I just stumbled upon), so
> please go ahead!
> 

For KNI, 0x%p is valid usage for printk(), so only sending patch for
vmxnet3.

Thanks,
ferruh
Thomas Monjalon June 23, 2016, 9:26 p.m. UTC | #5 
2016-06-20 12:44, Simon Kagstrom:
> I.e., avoid dump messages with double 0x0x, e.g.,
> 
>   dump mbuf at 0x0x7fac7b17c800, phys=17b17c880, buf_len=2176
>     pkt_len=2064, ol_flags=0, nb_segs=1, in_port=255
>     segment at 0x0x7fac7b17c800, data=0x0x7fac7b17c8f0, data_len=2064
> 
> Signed-off-by: Simon Kagstrom <simon.kagstrom@netinsight.net>

Applied, thanks
diff mbox

Patch

diff --git a/lib/librte_mbuf/rte_mbuf.c b/lib/librte_mbuf/rte_mbuf.c
index dc0467c..523e219 100644
--- a/lib/librte_mbuf/rte_mbuf.c
+++ b/lib/librte_mbuf/rte_mbuf.c
@@ -218,7 +218,7 @@  rte_pktmbuf_dump(FILE *f, const struct rte_mbuf *m, unsigned dump_len)
 
 	__rte_mbuf_sanity_check(m, 1);
 
-	fprintf(f, "dump mbuf at 0x%p, phys=%"PRIx64", buf_len=%u\n",
+	fprintf(f, "dump mbuf at %p, phys=%"PRIx64", buf_len=%u\n",
 	       m, (uint64_t)m->buf_physaddr, (unsigned)m->buf_len);
 	fprintf(f, "  pkt_len=%"PRIu32", ol_flags=%"PRIx64", nb_segs=%u, "
 	       "in_port=%u\n", m->pkt_len, m->ol_flags,
@@ -228,7 +228,7 @@  rte_pktmbuf_dump(FILE *f, const struct rte_mbuf *m, unsigned dump_len)
 	while (m && nb_segs != 0) {
 		__rte_mbuf_sanity_check(m, 0);
 
-		fprintf(f, "  segment at 0x%p, data=0x%p, data_len=%u\n",
+		fprintf(f, "  segment at %p, data=%p, data_len=%u\n",
 			m, rte_pktmbuf_mtod(m, void *), (unsigned)m->data_len);
 		len = dump_len;
 		if (len > m->data_len)