DPDK usage discussions
 help / color / mirror / Atom feed
From: "Hu, Jiayu" <jiayu.hu@intel.com>
To: Wisam Monther <wisamm@mellanox.com>
Cc: "users@dpdk.org" <users@dpdk.org>,
	Raslan Darawsheh <rasland@mellanox.com>,
	Shahaf Shuler <shahafs@mellanox.com>
Subject: Re: [dpdk-users] Unable to merge packets using GRO feature
Date: Tue, 22 Aug 2017 13:21:00 +0000	[thread overview]
Message-ID: <ED946F0BEFE0A141B63BABBD629A2A9B387A51A1@shsmsx102.ccr.corp.intel.com> (raw)
In-Reply-To: <AM3PR05MB307FAD10ECC48FEE0290F18A9840@AM3PR05MB307.eurprd05.prod.outlook.com>

Hi,

> -----Original Message-----
> From: Wisam Monther [mailto:wisamm@mellanox.com]
> Sent: Tuesday, August 22, 2017 7:07 PM
> To: Hu, Jiayu <jiayu.hu@intel.com>
> Cc: users@dpdk.org; Raslan Darawsheh <rasland@mellanox.com>; Shahaf
> Shuler <shahafs@mellanox.com>
> Subject: RE: Unable to merge packets using GRO feature
> 
> Hey Jiayu,
> 
> Thank you for your reply.
> I tried what you said with the csum at fwd mode.
> Even so the GRO didn't works fine.
> 
> I even tested with a new methodology.
> Two machines with two different nic for each.
> The methodology that I used to test it is described in the attached file.
> 
> What I did from gro side:
> """
> testpmd>gro on 1

Does the port number of NIC A in machine B is '1'? When you enable GRO for port '1',
Testpmd only tries to merge packets received from port '1'.

BRs,
Jiayu

> Testpmd>set fwd csum
> Testpmd>start
> """
> And the packet with correct dst mac.
> 
> Best regards,
> Wisam Jaddo
> -----Original Message-----
> From: Jiayu Hu [mailto:jiayu.hu@intel.com]
> Sent: Monday, August 21, 2017 12:14 PM
> To: Wisam Monther
> Cc: Thomas Monjalon; users@dpdk.org; Raslan Darawsheh; Shahaf Shuler
> Subject: Re: Unable to merge packets using GRO feature
> 
> Hi,
> 
> On Mon, Aug 21, 2017 at 07:25:23AM +0000, Wisam Monther wrote:
> > Hello Guys,
> >
> >
> >
> > I hope this finds you well, I’m trying to test the GRO feature. But
> > I’m stuck with this scenario.
> >
> > As you know, GRO is only support TCP_IPV4 packet until now.
> >
> > So I’m trying to test the basic functionality of the feature, as following:
> >
> > Start testpmd:
> >
> > “””
> >
> > ./x86_64-native-linuxapp-gcc/build/app/test-pmd/testpmd -n 4  -w
> > 00:0a.0  -w
> > 00:09.0 --  --burst=64 --mbcache=512 --portmask 0xf -i  --txd=512
> > --rxd=512
> > --nb-cores=9  --rxq=2 --txq=2 --txqflags=0
> >
> > “””
> >
> >
> >
> > Then enable GRO at the two ports:
> >
> > “””
> >
> > Testpmd>gro on 0
> >
> > Testpmd>gro on 1
> 
> When use GRO in testpmd, there are following things to notice:
> 
> 1. In testpmd, GRO is supported by csum forwarding engine. Therefore,
> please use 'set fwd csum' to switch forwarding engine.
> 
> 2. By default, csum forwarding engine compulsorily changes ethernet
> addresses. So please make sure that MAC addresses are correct.
> 
> 3. When enable GRO for port0, csum forwarding engine will merge packets
> received from port0. If there are no packets from port1 to port0, you don't
> need to enable GRO for port1.
> 
> 4. GRO library doesn't re-calculate checksums for merged packets. If you
> want merged packets have correct checksum, please select HW IP and HW
> TCP checksum calculation for the port which the merged packets are
> transmitted to in csum forwarding engine.
> This is because the merged packets are multi-segment mbufs, but csum
> forwarding engine doesn't support to calculate checksums for multi-segment
> mbufs in SW. So we need to select HW checksum offloading.
> 
> e.g. If data flow is "packets -> port0 -> port1", commands used in testpmd:
> 	gro on port0
> 	set fwd csum
> 	csum set ip hw port1
> 	csum set tcp hw port1
> 
> 
> Besides, you need to make sure that your PMD driver doesn't use vector TX
> function, since vector function doesn't support checksum offloading.
> 
> >
> > “””
> >
> >
> >
> > And trying to send TCP_IPV4 fragmented packet “packet with length 1500
> > fragmented to three packets of 500”
> >
> > “””
> >
> > p=Ether(src=get_if_hwaddr('ens10'), dst=
> > '24:8A:07:88:26:6B')/IP()/TCP()
> >
> > p.add_payload('F'*(1500 - len(p)))
> >
> > frags=fragment(p,fragsize=500)
> >
> > for fragment in frags:
> >
> >      sendp(fragment, iface='ens10')
> >
> > “””
> >
> >
> >
> > But the testpmd forward the packets as it is, “ doesn’t do any merge”
> >
> >
> >
> > Tcpdump at the TG side,
> >
> > The sending fragmets using ens10:
> >
> > #tcpdump –I ens10 –vvven
> >
> > 15:45:29.083514 24:8a:07:88:26:5b > 24:8a:07:88:26:6b, ethertype IPv4
> > (0x0800), length 538: (tos 0x0, ttl 64, id 1, offset 0, flags [+],
> > proto Options (0), length 524)
> >
> >     127.0.0.1 > 127.0.0.1:  ip-proto-0 504
> >
> > 15:45:29.115266 24:8a:07:88:26:5b > 24:8a:07:88:26:6b, ethertype IPv4
> > (0x0800), length 538: (tos 0x0, ttl 64, id 1, offset 504, flags [+],
> > proto Options (0), length 524)
> >
> >     127.0.0.1 > 127.0.0.1: ip-proto-0
> >
> > 15:45:29.147258 24:8a:07:88:26:5b > 24:8a:07:88:26:6b, ethertype IPv4
> > (0x0800), length 492: (tos 0x0, ttl 64, id 1, offset 1008, flags
> > [none], proto Options (0), length 478)
> >
> >     127.0.0.1 > 127.0.0.1: ip-proto-0
> >
> >
> >
> > #tcpdump -i ens9 –vvven  /// here will be received the forwarded
> > packets from
> > testpmd:
> >
> > 15:45:29.083996 24:8a:07:88:26:5b > 24:8a:07:88:26:6b, ethertype IPv4
> > (0x0800), length 538: (tos 0x0, ttl 64, id 1, offset 0, flags [+],
> > proto Options (0), length 524)
> >
> >     127.0.0.1 > 127.0.0.1:  ip-proto-0 504
> >
> > 15:45:29.115425 24:8a:07:88:26:5b > 24:8a:07:88:26:6b, ethertype IPv4
> > (0x0800), length 538: (tos 0x0, ttl 64, id 1, offset 504, flags [+],
> > proto Options (0), length 524)
> >
> >     127.0.0.1 > 127.0.0.1: ip-proto-0
> >
> > 15:45:29.147492 24:8a:07:88:26:5b > 24:8a:07:88:26:6b, ethertype IPv4
> > (0x0800), length 492: (tos 0x0, ttl 64, id 1, offset 1008, flags
> > [none], proto Options (0), length 478)
> >
> >     127.0.0.1 > 127.0.0.1: ip-proto-0
> >
> >
> >
> >
> >
> > Am I doing something wrong?! Or it is a bug.
> >
> > è As you see the tcpdump shows the offset of each fragment, and
> > testpmd prints L4_FRAG, so the both are recognizing that this is a
> fragmented packet.
> 
> GRO library merges TSOed/GSOed packets, whose IP IDs and TCP sequences
> are both consecutive. If input packets have same IP IDs, no packets will be
> merged.
> 
> BTW, you can use iperf to test GRO feature.
> 
> Best Regards,
> Jiayu
> 
> >
> >
> >
> > Best regards,
> >
> > Wisam Jaddo
> >
> >
> >

  reply	other threads:[~2017-08-22 13:21 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-21  7:25 Wisam Monther
2017-08-21  9:13 ` Jiayu Hu
2017-08-22 11:07   ` Wisam Monther
2017-08-22 13:21     ` Hu, Jiayu [this message]
2017-08-22 13:25       ` Wisam Monther
2017-08-24  5:47         ` Hu, Jiayu
2017-08-24  6:15           ` Wisam Monther
2017-08-28  7:36           ` Wisam Monther
2017-08-28  8:10             ` Hu, Jiayu
2017-08-29  1:51             ` Hu, Jiayu
2017-08-29  7:49               ` Wisam Monther
2017-09-06 11:17               ` Wisam Monther
2017-09-07  1:14                 ` Hu, Jiayu
2017-09-07  7:19                   ` Wisam Monther
2017-09-07  7:57                     ` Hu, Jiayu
2017-09-07  8:24                       ` Wisam Monther
2017-09-07  8:47                       ` Wisam Monther
2017-09-07  8:55                         ` Hu, Jiayu
2017-09-07  9:01                         ` Hu, Jiayu

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=ED946F0BEFE0A141B63BABBD629A2A9B387A51A1@shsmsx102.ccr.corp.intel.com \
    --to=jiayu.hu@intel.com \
    --cc=rasland@mellanox.com \
    --cc=shahafs@mellanox.com \
    --cc=users@dpdk.org \
    --cc=wisamm@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).