Message ID | 1438918156-1259-1-git-send-email-michael.qiu@intel.com (mailing list archive) |
---|---|
State | Accepted, archived |
Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@dpdk.org Delivered-To: patchwork@dpdk.org Received: from [92.243.14.124] (localhost [IPv6:::1]) by dpdk.org (Postfix) with ESMTP id 69C175960; Fri, 7 Aug 2015 05:29:26 +0200 (CEST) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 82CF7595C for <dev@dpdk.org>; Fri, 7 Aug 2015 05:29:24 +0200 (CEST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 06 Aug 2015 20:29:23 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.15,627,1432623600"; d="scan'208";a="778578860" Received: from shvmail01.sh.intel.com ([10.239.29.42]) by fmsmga002.fm.intel.com with ESMTP; 06 Aug 2015 20:29:24 -0700 Received: from shecgisg004.sh.intel.com (shecgisg004.sh.intel.com [10.239.29.89]) by shvmail01.sh.intel.com with ESMTP id t773TL2J009282; Fri, 7 Aug 2015 11:29:21 +0800 Received: from shecgisg004.sh.intel.com (localhost [127.0.0.1]) by shecgisg004.sh.intel.com (8.13.6/8.13.6/SuSE Linux 0.8) with ESMTP id t773THDj001294; Fri, 7 Aug 2015 11:29:20 +0800 Received: (from dayuqiu@localhost) by shecgisg004.sh.intel.com (8.13.6/8.13.6/Submit) id t773THdS001290; Fri, 7 Aug 2015 11:29:17 +0800 From: Michael Qiu <michael.qiu@intel.com> To: dev@dpdk.org Date: Fri, 7 Aug 2015 11:29:16 +0800 Message-Id: <1438918156-1259-1-git-send-email-michael.qiu@intel.com> X-Mailer: git-send-email 1.7.4.1 Subject: [dpdk-dev] [PATCH] testpmd: modify the mac of csum forwarding X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> |
Commit Message
Michael Qiu
Aug. 7, 2015, 3:29 a.m. UTC
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.
Signed-off-by: Michael Qiu <michael.qiu@intel.com>
---
app/test-pmd/csumonly.c | 4 ++++
1 file changed, 4 insertions(+)
Comments
Hi Michael, > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Michael Qiu > Sent: Friday, August 07, 2015 4:29 AM > 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. > > 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); > parse_ethernet(eth_hdr, &info); > l3_hdr = (char *)eth_hdr + info.l2_len; > > -- > 1.9.3 Why do you make this change only in this mode? If NICs like RRC has this issue, I assume it would happen in other modes. Thanks, Pablo
> -----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? > parse_ethernet(eth_hdr, &info); > l3_hdr = (char *)eth_hdr + info.l2_len; > > -- > 1.9.3
On 2015/8/7 9:05, De Lara Guarch, Pablo wrote: > Hi Michael, > >> -----Original Message----- >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Michael Qiu >> Sent: Friday, August 07, 2015 4:29 AM >> 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. >> >> 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); >> parse_ethernet(eth_hdr, &info); >> l3_hdr = (char *)eth_hdr + info.l2_len; >> >> -- >> 1.9.3 > Why do you make this change only in this mode? If NICs like RRC has this issue, > I assume it would happen in other modes. Yes, exactly, but for iofwd if we change the mac, so the mode is changed .... am I right? Thanks, Michael > Thanks, > Pablo >
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], >> + ð_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? 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. Thanks, Michael > >> parse_ethernet(eth_hdr, &info); >> l3_hdr = (char *)eth_hdr + info.l2_len; >> >> -- >> 1.9.3 >
> -----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], > >> + ð_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? > > 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? Regards, Helin > > Thanks, > Michael > > > >> parse_ethernet(eth_hdr, &info); > >> l3_hdr = (char *)eth_hdr + info.l2_len; > >> > >> -- > >> 1.9.3 > >
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], >>>> + ð_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? >> 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 >
> -----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
On 2015/8/7 17:13, Ouyang, Changchun wrote: > >> [.../...] >> >> 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? Yes, but I think it is no influence for checksum offload. Thanks, Michael >>> parse_ethernet(eth_hdr, &info); >>> l3_hdr = (char *)eth_hdr + info.l2_len; >>> >>> -- >>> 1.9.3 >
> -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Michael Qiu > Sent: Friday, August 07, 2015 11:29 AM > 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. > > 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); > parse_ethernet(eth_hdr, &info); > l3_hdr = (char *)eth_hdr + info.l2_len; > > -- > 1.9.3 The change will affect on the csum fwd performance. But I also think the change is necessary, or we cannot use csumonly fwd mode in guest。 Acked-by: Jijiang Liu <Jijiang.liu@intel.com>
Hi, all any other comments about this patch? Thanks, Michael On 8/26/2015 2:12 PM, Liu, Jijiang wrote: > >> -----Original Message----- >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Michael Qiu >> Sent: Friday, August 07, 2015 11:29 AM >> 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. >> >> 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); >> parse_ethernet(eth_hdr, &info); >> l3_hdr = (char *)eth_hdr + info.l2_len; >> >> -- >> 1.9.3 > The change will affect on the csum fwd performance. > But I also think the change is necessary, or we cannot use csumonly fwd mode in guest。 > > Acked-by: Jijiang Liu <Jijiang.liu@intel.com> > >
Hi, Thomas Any comments on this patch? Is it suitable for DPDK? Thanks, Michael On 2015/8/26 14:12, Liu, Jijiang wrote: > >> -----Original Message----- >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Michael Qiu >> Sent: Friday, August 07, 2015 11:29 AM >> 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. >> >> 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); >> parse_ethernet(eth_hdr, &info); >> l3_hdr = (char *)eth_hdr + info.l2_len; >> >> -- >> 1.9.3 > The change will affect on the csum fwd performance. > But I also think the change is necessary, or we cannot use csumonly fwd mode in guest。 > > Acked-by: Jijiang Liu <Jijiang.liu@intel.com> > >
2015-10-13 06:29, Qiu, Michael: > Hi, Thomas > > Any comments on this patch? Is it suitable for DPDK? Please check with the testpmd maintainer. Pablo?
HI, > -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > Sent: Saturday, October 24, 2015 5:52 PM > To: Qiu, Michael > Cc: dev@dpdk.org; Liu, Jijiang; De Lara Guarch, Pablo > Subject: Re: [dpdk-dev] [PATCH] testpmd: modify the mac of csum > forwarding > > 2015-10-13 06:29, Qiu, Michael: > > Hi, Thomas > > > > Any comments on this patch? Is it suitable for DPDK? > > Please check with the testpmd maintainer. > Pablo? The patch looks harmless for other NICs, and it does similar stuff as other forwarding modes, so I think it is safe to integrate. Thanks, Pablo
2015-10-26 19:47, De Lara Guarch, Pablo: > > 2015-10-13 06:29, Qiu, Michael: > > > Hi, Thomas > > > > > > Any comments on this patch? Is it suitable for DPDK? > > > > Please check with the testpmd maintainer. > > Pablo? > > The patch looks harmless for other NICs, and it does similar stuff as other forwarding modes, > so I think it is safe to integrate. Applied, thanks
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); parse_ethernet(eth_hdr, &info); l3_hdr = (char *)eth_hdr + info.l2_len;