On 2015/8/7 9:06, Zhang, Helin wrote:
>
>> -----Original Message-----
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Michael Qiu
>> Sent: Thursday, August 6, 2015 8:29 PM
>> To: dev at 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 at 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.

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

Reply via email to