From: "Ouyang, Changchun" <changchun.ouyang@intel.com>
To: "Zhang, Helin" <helin.zhang@intel.com>,
"Qiu, Michael" <michael.qiu@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH] testpmd: modify the mac of csum forwarding
Date: Sat, 8 Aug 2015 00:13:26 +0000 [thread overview]
Message-ID: <F52918179C57134FAEC9EA62FA2F962511C6E983@shsmsx102.ccr.corp.intel.com> (raw)
In-Reply-To: <F35DEAC7BCE34641BA9FAC6BCA4A12E70A8BCD4A@SHSMSX104.ccr.corp.intel.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Zhang, Helin
> Sent: Saturday, August 8, 2015 12:07 AM
> To: Qiu, Michael; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] testpmd: modify the mac of csum
> forwarding
>
>
>
> > -----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.
>
> >
> > 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],
> > + ð_hdr->d_addr);
> > + ether_addr_copy(&ports[fs->tx_port].eth_addr,
> > + ð_hdr->s_addr);
> Is it really necessary? Why other NICs do not need this?
>
Seems the behavior changes from io fwd into mac fwd?
> > parse_ethernet(eth_hdr, &info);
> > l3_hdr = (char *)eth_hdr + info.l2_len;
> >
> > --
> > 1.9.3
next prev parent reply other threads:[~2015-08-08 0:13 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
2015-08-08 0:13 ` Ouyang, Changchun [this message]
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=F52918179C57134FAEC9EA62FA2F962511C6E983@shsmsx102.ccr.corp.intel.com \
--to=changchun.ouyang@intel.com \
--cc=dev@dpdk.org \
--cc=helin.zhang@intel.com \
--cc=michael.qiu@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).