DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Qiu, Michael" <michael.qiu@intel.com>
To: "Zhang, Helin" <helin.zhang@intel.com>, "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH] testpmd: modify the mac of csum forwarding
Date: Fri, 7 Aug 2015 21:16:11 +0000	[thread overview]
Message-ID: <533710CFB86FA344BFBF2D6802E6028604703973@SHSMSX101.ccr.corp.intel.com> (raw)
In-Reply-To: <F35DEAC7BCE34641BA9FAC6BCA4A12E70A8BCF51@SHSMSX104.ccr.corp.intel.com>

On 2015/8/7 13:37, Zhang, Helin wrote:
>
>> -----Original Message-----
>> From: Qiu, Michael
>> Sent: Friday, August 7, 2015 11:53 AM
>> To: Zhang, Helin; dev@dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH] testpmd: modify the mac of csum forwarding
>>
>> On 2015/8/7 9:06, Zhang, Helin wrote:
>>>> -----Original Message-----
>>>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Michael Qiu
>>>> Sent: Thursday, August 6, 2015 8:29 PM
>>>> To: dev@dpdk.org
>>>> Subject: [dpdk-dev] [PATCH] testpmd: modify the mac of csum
>>>> forwarding
>>>>
>>>> For some ethnet-switch like intel RRC, all the packet forwarded out
>>>> by DPDK will be dropped in switch side, so the packet generator will never
>> receive the packet.
>>> Is it because of anti-sproof? E.g. When the hardware found that the
>>> dest mac is the port itself, then it will be dropped during TX.
>>> You need to tell the root cause, and why we need to modify like this.
>> Actually, it is not the hardware from PEP(PCI End Point) side, but the switch side.
>>
>> The TX is OK for DPDK and NIC, but in switch, it receives the packet and try to
>> forward it, but the dest mac is the same as the NIC which transmit this packet.
>> So switch will drop it as "Loopback Suppression Drop" in RRC. This should only
>> happen when switch forwarding packets using dest mac.
>>
>>
>>>> Signed-off-by: Michael Qiu <michael.qiu@intel.com>
>>>> ---
>>>>  app/test-pmd/csumonly.c | 4 ++++
>>>>  1 file changed, 4 insertions(+)
>>>>
>>>> diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c index
>>>> 1bf3485..bf8af1d 100644
>>>> --- a/app/test-pmd/csumonly.c
>>>> +++ b/app/test-pmd/csumonly.c
>>>> @@ -550,6 +550,10 @@ pkt_burst_checksum_forward(struct fwd_stream
>> *fs)
>>>>  		 * and inner headers */
>>>>
>>>>  		eth_hdr = rte_pktmbuf_mtod(m, struct ether_hdr *);
>>>> +		ether_addr_copy(&peer_eth_addrs[fs->peer_addr],
>>>> +				&eth_hdr->d_addr);
>>>> +		ether_addr_copy(&ports[fs->tx_port].eth_addr,
>>>> +				&eth_hdr->s_addr);
>>> Is it really necessary? Why other NICs do not need this?
>> Because other NICs is connect directly to packet generator...., if we using switch
>> to connect the generator and the NICs, I think it will need this.
> There are 'iofwd' and 'mac' mode in testpmd, and mac forware will modify the dest
> mac before transmitting the packet. They are for different cases.
> Why not use mac forwarding mode for your testing, and just keep it as is?

Yes, I don't touch iofwd, I just modify the csum, when we test checksum
offload, especially for checksum insert in TX side.

Thanks,
Michael

> Regards,
> Helin
>
>> Thanks,
>> Michael
>>>>  		parse_ethernet(eth_hdr, &info);
>>>>  		l3_hdr = (char *)eth_hdr + info.l2_len;
>>>>
>>>> --
>>>> 1.9.3
>


  reply	other threads:[~2015-08-07 21:16 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-07  3:29 Michael Qiu
2015-08-07 16:05 ` De Lara Guarch, Pablo
2015-08-07 18:42   ` Qiu, Michael
2015-08-07 16:06 ` Zhang, Helin
2015-08-07 18:52   ` Qiu, Michael
2015-08-07 20:37     ` Zhang, Helin
2015-08-07 21:16       ` Qiu, Michael [this message]
2015-08-08  0:13   ` Ouyang, Changchun
2015-08-10  4:45     ` Qiu, Michael
2015-08-26  6:12 ` Liu, Jijiang
2015-09-14  3:37   ` Qiu, Michael
2015-10-13  6:29   ` Qiu, Michael
2015-10-24 16:52     ` Thomas Monjalon
2015-10-26 19:47       ` De Lara Guarch, Pablo
2015-10-29 22:55         ` 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=533710CFB86FA344BFBF2D6802E6028604703973@SHSMSX101.ccr.corp.intel.com \
    --to=michael.qiu@intel.com \
    --cc=dev@dpdk.org \
    --cc=helin.zhang@intel.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).