I set the dataroom of the mbuf from 2048 to 64B. To receive large packets（>64B） with a 64B size dataroom mbuf, DPDK reminds me that I need to enable scattered mode. So how can I enable scattered mode?
Rx scatter can be enabled at the stage when rte_eth_dev_configure() is invoked. To do that, one should pass flag RTE_ETH_RX_OFFLOAD_SCATTER via dev_conf.rx_mode.offloads, with dev_conf being passed by pointer as the last argument to rte_eth_dev_configure().
To check the feature with testpmd, one can pass command-line argument --enable-scatter.
Related
I'm creating an application that reads from some source cluster/topic then does some processing on the message and finally writes to a destination cluster/topic. I would like to only move the offset when the message passes the processing phase. Do I just need to set spring.kafka.consumer.enable-auto-commit=false? Or do I need to also implement an AcknowledgingMessageListener or a ConsumerAwareMessageListener and do either consumer.commitSync() or ack.acknowledge()?
Created a plain MessageListener.
Yes, you need at least an AcknowledgingMessageListener and set the container's AckMode to MANUAL or MANUAL_IMMEDIATE.
See https://docs.spring.io/spring-kafka/docs/current/reference/html/#committing-offsets
I need to write driver (DXE), that can transmit "couple of bytes" from virtual machine (QEMU) to the host system (OS - Ubuntu). I've read the UEFI_Spec and Guide for developers, but I still don't understand, how to write the code and what protocol should I use (tried to use TCPv4 but can't even LocateHandleBuffer).
EFI_STATUS Status = gBS->LocateHandleBuffer(ByProtocol, &gEfiTcp4ProtocolGuid, NULL, &HandleCount, &HandleBuffer);
I get:
EFI_UNSUPPORTED
If somebody can explain me or can show examples of the code, I'll be very grateful. Thanks.
For most network related protocols you first have to use the corresponding "Service Binding Protocol" to get a handle which contains the protocol you are looking for.
Use this steps to access the Tcp4Protocol:
gBS->LocateHandleBuffer(ByProtovol,gEfiTcp4ServiceBindingProtocolGuid, NULL, &HandleCount, &HandleBuffer);
// Loop over the HandleBuffer Array and pick the one you need
gBS->HandleProtocol(HandleBuffer[YourIndex], &gEfiTcp4ServiceBindingProtocolGuid, &Tcp4SBProtocol);
Tcp4SBProtocol->CreateChild(Tcp4SBProtocol, &Tcp4Handle);
gBS->HandleProtocol(Tcp4Handle, &gEfiTcp4ProtocolGuid, &Tcp4Protocol);
To check if a NIC is available you can use:
// This should return EFI_SUCCESS
gBS->LocateProtocol(&gEfiSimpleNetworkProtocolGuid, NULL, &SimpleNetworkProtocol);
There is a complete code sample for the HttpProtocol inside the Uefi specification (starting at page 1548), the Tcp4Protocol is not very different.
I have the following problem:
STM32F7 Flash starts at 0x0800 0000. My program works fine.
Then I shift my code in FLASH at 0x0802 0000 to leave space for future bootloader. I changed my MemoryMap.xml file :
<MemorySegment start="0x08020000" name="FLASH" size="0x80000" access="ReadOnly"/>
and the corresponding flashplacement.xml file:
<ProgramSection alignment="0x100" load="Yes" name=".vectors" start=" 0x8020000"/>
and start debuging....Program works fine until an link error occurs which triggers a system restart with a call of HAL_NVIC_SystemReset.
The result is a hanging application which is not the case when my code resides at the start of FLASH (0x0800 0000)
Does anybody knows why is this happens?
Regards
/Kostas
The answer is rather easy. You cant just move memory start address. Your micro will get the stack pointer value and the reset handler routine address from the same address as usually. You need to have this boot loader already flashed( at least the vector table and the reset handler which will set the new vector table, set the app stack pointer and pass the control to your app reset handlet
I am using WsReceive() function of the ATEasy framework and wanted to ask what is the meaning of the values "aioDefault
and aioDisableWsReceiveEarlyReturn" of "enMode" parameter?
I found this in the ATEASY documentation:
If enMode, input receive mode includes aioDisableWsReceiveEarlyReturn,
it prevents WsReceive from an "early return" when there is a momentary
interruption in the data being received.
And this from the online help of ateasy (By a tip of an expert from the ateasy forum) :
If sEos parameter is an empty string and aioDisableWsReceiveEarlyReturn mode flag is not used (default case), the function will return immediately if characters are found in the input buffer, and the timeout will be ignored. Using the aioDisableWsReceiveEarlyReturn flag will ensure that the function will return only if the timeout is reached or all lBytes characters were received.
I'm getting the OMX_ErrorUnsupportedSetting error event after providing the buffers to an audio decoder component on Raspberry Pi. I tried anything that came into my mind to change the parameters but still the callback arrives. Is there any way in the OpenMAX standard to try to investigate what parameter is causing that event?
This is what I'm doing:
Created the component;
disabled all the ports;
set state to idle;
set port format to use OMX_AUDIO_CodingAAC;
set port definition to use OMX_AUDIO_CodingAAC, 4 buffers of 6144 bytes each;
set profile to these values (not sure if needed): profileType.nSampleRate = 48000; profileType.nFrameLength = 0; profileType.nChannels = 6; profileType.nBitRate = 288000; profileType.nAudioBandWidth = 0; set OMX_PARAM_CODECCONFIGTYPE with bCodecConfigIsComplete to 1;
set OMX_IndexParamBrcmDecoderPassThrough to true.
After all the buffers are sent to the component, I suddenly get OMX_ErrorUnsupportedSetting event and the port is not enabled. Any idea of what I may be doing wrong or how I can inspect the parameter which is causing the error?
I've been told by the manufacturer that the reason this is happening is that no audio decoder except PCM is available at the moment.