Can UDPST run on RDK-B's platform via HW accel?

[lixingang-1993]

I'm trying to integrate the UDPST to RDK-B platform.
On RDK-B broadcom 3390, bspeed is a HW accel module for UDP throughtput test.
But bspeed module only return the length of payload and the length is the length of multiple UDP packets, so the client can not verify the PDU and calcuate the UDP packets count.

Is there a solution to this situation?

thanks
Xingang Li

[lc9892]

There might be an easy solution.
In the Load PDU header there is a field called "udpPayload"...
struct loadHdr {
...
uint16_t udpPayload; // UDP payload (bytes)
...
};

The sending side populates it so that when the receiver only asks to receive the Load PDU number of bytes from the protocol stack, to save the memory copy of the filler bytes, it can still calculate accurate stats. For example, the existing code uses it like this:
//
// Update traffic stats (use size specified in PDU, actual receive may have been truncated)
//
payload = (unsigned int) ntohs(lHdr->udpPayload);
c->sisAct.rxDatagrams++;
c->sisAct.rxBytes += (uint64_t) payload;
c->tiRxDatagrams++;
c->tiRxBytes += payload;

If I understand your issue correctly, you should be able to use that field in the first datagram to find the second one and then use it in the second one to find the third...and so on.

Hope that helps, otherwise let me know.
Len

[lixingang-1993]

这是来自QQ邮箱的假期自动回复邮件。   您好，邮件已收到，暂时无法亲自回复您的邮件。尽快给您回复。

[lixingang-1993]

Hi Len, Thanks for your help.But it's very very complicated. Broadcom bspeed driver is a very special module, this driver only used for through tput test. The bspeed driver is a kernel module and broadcom only provide some APIs for used. For UDP thoughtput test, after UDP connection is established, need add the socket fd to the bspeed driver, then we can read the length of received buffer from bspeed driver. But the bspeed driver only return the length of received buffer, can't read the received buffer from the bspeed driver. Also the length not include the UDP header(eg. the length read from the bspeed driver is 12220(10 packets), while the UDP total length is 1264). thanks Xingang Li

…

---Original--- From: "Len ***@***.***> Date: Fri, Oct 18, 2024 22:04 PM To: ***@***.***>; Cc: ***@***.******@***.***>; Subject: Re: [BroadbandForum/obudpst] Can UDPST run on RDK-B's platform via HWaccel? (Issue #17) There might be an easy solution. In the Load PDU header there is a field called "udpPayload"... struct loadHdr { ... uint16_t udpPayload; // UDP payload (bytes) ... }; The sending side populates it so that when the receiver only asks to receive the Load PDU number of bytes from the protocol stack, to save the memory copy of the filler bytes, it can still calculate accurate stats. For example, the existing code uses it like this: // // Update traffic stats (use size specified in PDU, actual receive may have been truncated) // payload = (unsigned int) ntohs(lHdr->udpPayload); c->sisAct.rxDatagrams++; c->sisAct.rxBytes += (uint64_t) payload; c->tiRxDatagrams++; c->tiRxBytes += payload; If I understand your issue correctly, you should be able to use that field in the first datagram to find the second one and then use it in the second one to find the third...and so on. Hope that helps, otherwise let me know. Len — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[lc9892]

It sounds like you can only get the length and not any of the data. If so, that driver can only be used for a simple saturation test, not a more advanced test that adjusts the sending rate based on packet loss (as indicated by sequence number gaps). Also, the status feedback messages going in the opposite direction need to be read as well. Both are part of the protocol.

Are there alternatives to that driver or any option to get the data? I know that Broadcom has integrated the code into a number of RGs (e.g., BGW-320) using an offload capability in their device driver that bypasses the normal protocol stack. However, in that case the driver does pass all the data back and forth.

If you can't actually get any of the received data (and only the lengths), I don't know if there's much you can do to support a TR-471 test. Have you used the software without using the bspeed driver API? Does that work on the device (even if slower than you'd like)?

Len

[lixingang-1993]

Hi Len, I try the UDPST without using the bspeed driver, it's work fine. Since no way to resolve this,  I will integrate UFPST without using bspeed driver, hope the customer can accept this. Thank you. I appreciate your help. Xijgang Li

…

---Original--- From: "Len ***@***.***> Date: Sat, Oct 19, 2024 00:44 AM To: ***@***.***>; Cc: ***@***.******@***.***>; Subject: Re: [BroadbandForum/obudpst] Can UDPST run on RDK-B's platform via HWaccel? (Issue #17) It sounds like you can only get the length and not any of the data. If so, that driver can only be used for a simple saturation test, not a more advanced test that adjusts the sending rate based on packet loss (as indicated by sequence number gaps). Also, the status feedback messages going in the opposite direction need to be read as well. Both are part of the protocol. Are there alternatives to that driver or any option to get the data? I know that Broadcom has integrated the code into a number of RGs (e.g., BGW-320) using an offload capability in their device driver that bypasses the normal protocol stack. However, in that case the driver does pass all the data back and forth. If you can't actually get any of the received data (and only the lengths), I don't know if there's much you can do to support a TR-471 test. Have you used the software without using the bspeed driver API? Does that work on the device (even if slower than you'd like)? Len — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>