L2 포워딩에서 DPDK 패킷 손실 방지

Question

안녕하세요. DPDK 용 핑퐁을 구현했습니다. 클라이언트가 패킷을 보내고 서버가 패킷을 수신 한 다음이를 반환합니다.

서버 부분은 DPDK 공식 웹 사이트의 L2 전달 샘플과 유사하게 구현됩니다.

L2 포워딩을 수행하는 동안 수신 대기열에서 전송 대기열로 패킷을 전달하는 동안 패킷 손실이 있음을 발견했습니다.

내 질문은 ... 패킷 손실을 0으로 만드는 방법이 있습니까?

DPDK 웹 사이트의 샘플 애플리케이션에 패킷 손실이 있기 때문에 해결책을 찾지 못했습니다.

패킷 손실

rte_eth_tx_buffer_set_err_callback(tx_buffer[portid], rte_eth_tx_buffer_count_callback, &port_statistics[portid].dropped); 

이하 콜백 함수에 의해 계산되고,이 내 구현 단지 탁구 매우 간단한 구현이되므로

Port statistics ==================================== 
Statistics for port 0 ------------------------------ 
Packets sent:     384126    
Packets received:    379889    
Packets dropped:     4237    
Aggregate statistics =============================== 
Total packets sent:    384126    
Total packets received:   379889    
Total packets dropped:   4237    
==================================================== 

전달 I가 L2에서이 결과 제 경우에는 패킷 손실이 발생한다고 생각하지 않습니다.

Answer 1

Packets droppedrte_eth_tx_burst()이 대상 포트로 패킷을 전송할 수없는 경우 rte_eth_tx_buffer_flush()에 카운터가 증가하고 있습니다.

rte_eth_tx_burst() 함수는 단순히 tx_pkt_burst() PMD 콜백을 호출하기 때문에 아래의 PMD에 대한 정보가 없으면 왜 실패하는지 알기 어렵습니다. 그럼 다음 섹션은 꽤 추측입니다.

TX 대기열이 가득하기 때문에 일반적으로 rte_eth_tx_burst()이 실패합니다. 장치 아래에서 사용자가 제공 한 속도로 패킷을 보낼 수 없기 때문에 TX 대기열이 가득 찼습니다.

이 일어날 수있는 몇 가지 경우가 있습니다

1. 귀하의 RX 포트 속도가 귀하의 TX 포트 속도보다 큰 (아마 당신의 경우가 아니다).

2. RX 및 TX 포트의 속도는 같지만 앱에 추가 패킷이 추가되어 더 이상 맞지 않습니다 (사용자의 경우 일 수 있음).

3. 귀하의 NIC가 흐름 제어로 인해 전송을 일시 중지하고 있으므로 해당 드랍이 있습니다 (대부분 그럴 것 같습니다). 내 생각이 잘못된 경우

   ethtool -A eth0 tx off rx off 
   

   , 다음 서버 측에서 PMD 파고 : 내 생각이 맞다면

그래서, 그냥 ethtool와 클라이언트 측에서 이더넷 흐름 제어를 비활성화 카운터가 rte_eth_stats_get() 및 rte_eth_xstats_get() 인 경우 무슨 일이 일어나고 있는지 확인하십시오.