As a new DPDK user, I am grateful if someone can help answer following basic questions.
I see from the document and source code, there are packet type (e.g.,
172 IPV4 GTPU IPV4 TCP PAY4), packet classification type (pctype),
and flow type (e.g., 0 to 22). What are these types and their
relations?
DPDK has to map hardware type (pctype?) to the software
flow type to run RSS. Why is this and how it is done?
DPDK has mempool and it can allocate interleaved memory based on channels and ranks. But I don't understand how it is done (e.g., in the two figures in the link).
Last question is about the pktgen. Can it send e.g., 10 packets and stop? Or can it send pcap file once after it's loaded? I found it just keeps sending packets over and over.
Thanks.
Can it send e.g., 10 packets and stop?
Yes
set 0 count 10
While 0 is the port number
We've used pktgen-dpdk to send 1000000 packets and the remote could receive such number of packets.
Related
I am writing a program for receiving udp multicast packet. I came across short read. Is that applicable to udp? How do I ensure that I read one packet at a time? Is that possible?
My packet has a fixed size header followed by a variable length body.
https://www.boost.org/doc/libs/1_60_0/doc/html/boost_asio/overview/core/streams.html#:~:text=When%20a%20short%20read%20or,write()%20and%20async_write()%20.
"I came across short read"
What does that mean? You mean you "heard about it"? Or received the error?
Is that applicable to udp?
No. UDP is connectionless and DATAGRAM.
How do I ensure that I read one packet at a time?
That's how UDP works.
Is that possible?
Something else is not possible, although you can set flags that allow an incomplete datagram when the supplied buffer is too small to receive the complete datagram.
My packet has a fixed size header followed by a variable length body.
SUMMARY
The title of the page you linked was Streams, Short Reads and Short Writes. Your sockets are UDP, that is, not streams.
I've been experimenting with isochronous USB transfers using WinUsb, and it turns out that WinUsb always sends data as fast as possible:
WinUsb_WriteIsochPipe packetizes the transfer buffer so that in each interval, the host can send the maximum bytes allowed per interval.
However for the kernel drivers you can apparently send shorter packets:
The MaximumPacketSize value indicates the maximum permitted size of the isochronous packet. The client driver can set the size of each isochronous packet to any value less than the MaximumPacketSize value.
I wondered how USB audio handles this. As far as I can see in the spec they just two alternative configurations for the interface - a zero bandwidth one, and a non-zero bandwidth one. There is a flag that says whether the endpoint requires full-size packets or not.
So my questions are:
a) What is the best way to handle sending less than full-speed data. Should I have a whole array of alternate configurations with different max packet sizes?
b) Should I expect to be able to send shorter-than-maximum packets? If so why doesn't WinUsb allow this?
Maybe you have to call WinUsb_WriteIsochPipe once for each packet you want to send. Make sure to use asynchronous I/O so you can queue up dozens or hundreds of requests ahead of time.
Hi I am writing a program that will send a file from client to server using UDP socket using different packet sizes for example 512B, 1KB and 2KB and i don't want use fixed buffer size in the receiver(server).I need some codes in Java that will allow both server and client to agree upon a packet size before transfer start. Many thanks
Don't you forget that UDP packets may be fragmented, duplicated and lost? There is a whole bunch of things to take care of, starting with lost packet retransmissions.
I hate to give a "don't do this" kind of answers, but for this one, just use TCP. And if you want some user-level "packets", you can have them with TCP also (prefix each one with its length, that's enough).
It seems that a UDP packet can be sent without a payload.
The only thing I can think of that doesn't need a payload is for NAT hole punching.
What else could this be used for?
This relates to my previous question Under Linux, can recv ever return 0 on UDP?
I suppose more to the point is that if it's been specified as part of some standard, then it's been thought to be useful somewhere right?
Anything! The UDP packet isn't empty -- it comes with the sender's identity. Therefore, such a packet could be used as a primitive kind of signal: maybe a hello, a goodbye, or a keep-alive.
With interfaces like sendmsg, an empty packet might be used in order to send auxiliary data, like a cmsg structure (which can be used for things like transferring file descriptors between two processes on Linux).
EDIT: One more use: NAT traversal algorithms such as STUN or UDP hole punching.
To answer the question of "why would a protocol do this": the old Daytime protocol just uses the arrival of a UDP packet to send back a reply packet. Similarly, it replies with time value as soon as a TCP connection happens regardless of any actual data that the TCP connection contains.
a UDP packet without payload may be sent to detect if a UDP port is closed. if closed, an ICMP-unreach is replied.
I am writing code for a USB device. Suppose the USB host starts a control read transfer to read some data from the device, and the amount of data requested (wLength in the Setup Packet) is a multiple of the Endpoint 0 max packet size. Then after the host has received all the data (in the form of several IN transactions with maximum-sized data packets), will it initiate another IN transaction to see if there is more data even though there can't be more?
Here's an example sequence of events that I am wondering about:
USB enumeration process: max packet size on endpoint 0 is reported to be 64.
SETUP-DATA-ACK transaction starts a control read transfer, wLength = 128.
IN-DATA-ACK transaction delivers first 64 bytes of data to host.
IN-DATA-ACK transaction delivers last 64 bytes of data to host.
IN-DATA-ACK with zero-length DATA packet? Does this transaction ever happen?
OUT-DATA-ACK transaction completes Status Phase of the transfer; transfer is over.
I tested this on my computer (Windows Vista, if it matters) and the answer was no: the host was smart enough to know that no more data can be received from the device, even though all the packets sent by the device were full (maximum size allowed on Endpoint 0). I'm wondering if there are any hosts that are not smart enough, and will try to perform another IN transaction and expect to receive a zero-length data packet.
I think I read the relevant parts of the USB 2.0 and USB 3.0 specifications from usb.org but I did not find this issue addressed. I would appreciate it if someone can point me to the right section in either of those documents.
I know that a zero-length packet can be necessary if the device chooses to send less data than the host requested in wLength.
I know that I could make my code flexible enough to handle either case, but I'm hoping I don't have to.
Thanks to anyone who can answer this question!
Read carefully USB specification:
The Data stage of a control transfer from an endpoint to the host is complete when the endpoint does one of
the following:
Has transferred exactly the amount of data specified during the Setup stage
Transfers a packet with a payload size less than wMaxPacketSize or transfers a zero-length packet
So, in your case, when wLength == transfer size, answer is NO, you don't need ZLP.
In case wLength > transfer size, and (transfer size % ep0 size) == 0 answer is YES, you need ZLP.
In general, USB uses a less-than-max-length packet to demarcate an end-of-transfer. So in the case of a transfer which is an integer multiple of max-packet-length, a ZLP is used for demarcation.
You see this in bulk pipes a lot. For example, if you have a 4096 byte transfer, that will be broken down into an integer number of max-length packets plus one zero-length-packet. If the SW driver has a big enough receive buffer set up, higher-level SW receives the entire transfer at once, when the ZLP occurs.
Control transfers are a special case because they have the wLength field, so ZLP isn't strictly necessary.
But I'd strongly suggest SW be flexible to both, as you may see variations with different USB host silicon or low-level HCD drivers.
I would like to expand on MBR's answer. The USB specification 2.0, in section 5.5.3, says:
The Data stage of a control transfer from an endpoint to the host is
complete when the endpoint does one of the following:
Has transferred exactly the amount of data specified during the Setup stage
Transfers a packet with a payload size less than wMaxPacketSize or transfers a zero-length packet
When a Data stage is complete, the Host Controller advances to the
Status stage instead of continuing on with another data transaction.
If the Host Controller does not advance to the Status stage when the
Data stage is complete, the endpoint halts the pipe as was outlined in
Section 5.3.2. If a larger-than-expected data payload is received from
the endpoint, the IRP for the control transfer will be
aborted/retired.
I added emphasis to one of the sentences in that quote because it seems to specifically say what the device should do: it should "halt" the pipe if the host tries to continue the data phase after it was done, and it is done if all the requested data has been transmitted (i.e. the number of bytes transferred is greater than or equal to wLength). I think halting refers to sending a STALL packet.
In other words, the device does not need a zero-length packet in this situation and in fact the USB specification says it should not provide one.
You don't have to. (*)
The whole point of wLength is to tell the host the maximum number of bytes it should attempt to read (but it might read less !)
(*) I have seen devices that crash when IN/OUT requests were made at incorrect time during control transfers (when debugging our host solution). So any host doing what you are worried about, would of killed those devices and is hopefully not in the market.