Re: [edk2-devel] reg: PCD To Control MNP Buffer Recycle Support

["Maciej Rabeda" <maciej.rabeda@linux.intel.com>]

[-- Attachment #1: Type: text/plain, Size: 1874 bytes --]

Hi Nainar,

What do you mean by "controllers do not support recycling of Tx buffers"?
MNP provides a transmit buffer to SNP (and with EDK2's SNP also to UNDI) 
and at this point it is considered owned by SNP/UNDI.
After UNDI/SNP successfully transmits the packet, it is expected to give 
it back via UNDI->GetStatus().

Adding network controller (NIC) and UNDI into the picture.

1. UNDI->Transmit() gets a single Tx buffer to put on the wire.
2. If a NIC has a pre-allocated region for Tx buffers and cannot 
dynamically swap them out, UNDI->Transmit() should copy the Tx buffer 
into appropriate region. UNDI driver should also store that Tx buffer 
somewhere within the driver, where it will be accessible by 
UNDI->GetStatus() function.
3. After successful transmit of Tx buffer, on next UNDI->GetStatus() 
with PXE_OPFLAGS_GET_TRANSMITTED_BUFFERS OpFlag, driver should put that 
Tx buffer address in PXE_CDB.DBAddr provided to UNDI->GetStatus() as a 
parameter.

Summing the above - Tx buffer recycling is purely a SW feature. I do not 
understand your request nor find it valid.

Thanks,
Maciej

On 24-Nov-20 15:30, Sivaraman Nainar wrote:
>
> Hello all:
>
> MNPDxe supported with the Recycle buffer support from the below git 
> commit,
>
> https://github.com/tianocore/edk2/commit/0507449955c5c629cec196b62986afbb91203ed9#diff-fb5b97ad38efea22f5ddd745f6e43ebdb509dc4a5aef81997ba53af5f918a47b 
> <https://github.com/tianocore/edk2/commit/0507449955c5c629cec196b62986afbb91203ed9#diff-fb5b97ad38efea22f5ddd745f6e43ebdb509dc4a5aef81997ba53af5f918a47b>
>
> But many network controllers does not support the Recycling Tx Buffers 
> which will cause the PXE Download failure or HTTP Boot failure.
>
> Can this feature can be controlled by a Dynamic PCD so that the same 
> code can work for controller which does not support Tx Buffer Recycling.
>
> Thanks
>
> Siva
>
> 


[-- Attachment #2: Type: text/html, Size: 4264 bytes --]