Hello Maciej:

As per the PXE Spe= cification:

The protocol driver c= alls UNDI repeatedly with the FuncFlag equal to PXENV_UNDI_ISR_IN_GET_NEXT = to get all the buffers in a frame and also all the received

frames in the queue. = On this call, UNDI must remember the previous buffer given to the protoco,l= remove it from the receive queue and recycle it. In case of a multi-buffer= ed frame, if the previous

buffer is not the las= t buffer in the frame it must return the next buffer in the frame in the pa= rameter block. Otherwise it must return the first buffer in the next frame.=

Assume the UNDI Drive= r does not properly Store that TxAddress in the GetStatus then the possibil= ity of MNP Layer having issues when it treats the recycling based on the Ge= tStatus.

2. If a NIC has a pre-allocated region for Tx buffe= rs and cannot dynamically swap them out, UNDI->Transmit() should copy th= e 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.

When this point 2 fai= ls the Recycle support done in the SW Layer shall also fail.

Pleases correct my un= derstanding if any .

-Siva

From: Rabeda, Maciej [mailto:maciej.rabeda@l= inux.intel.com]
Sent: Thursday, November 26, 2020 9:10 PM
To: devel@edk2.groups.io; Sivaraman Nainar
Subject: Re: [edk2-devel] reg: PCD To Control MNP Buffer Recycle Su= pport

Hi Nainar,

What do you mean by "controllers do not support recycling of Tx buffe= rs"?
MNP provides a transmit buffer to SNP (and with EDK2's SNP also to UNDI) a= nd at this point it is considered owned by SNP/UNDI.
After UNDI/SNP successfully transmits the packet, it is expected to give i= t 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 dynamical= ly swap them out, UNDI->Transmit() should copy the Tx buffer into approp= riate 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() wi= th PXE_OPFLAGS_GET_TRANSMITTED_BUFFERS OpFlag, driver should put that Tx bu= ffer address in PXE_CDB.DBAddr provided to UNDI->GetStatus() as a parame= ter.

Summing the above - Tx buffer recycling is purely a SW feature. I do not u= nderstand 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 fr= om the below git commit,

https://github.com/tianocore/edk2/com= mit/0507449955c5c629cec196b62986afbb91203ed9#diff-fb5b97ad38efea22f5ddd745f= 6e43ebdb509dc4a5aef81997ba53af5f918a47b

But many network controllers does not support the R= ecycling 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 Bu= ffer Recycling.

Thanks

Siva