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

[Maciej Rabeda]

You are referring to the wrong document (PXE 2.1 spec for 16-bit 
UNDIs/legacy BIOS).
Appendix E of UEFI specification defines UNDI functions, behaviors and 
supported opcodes in UEFI.

Thanks,
Maciej

On 26-Nov-20 17:20, Sivaraman Nainar wrote:
>
> Hello Maciej:
>
> *As per the PXE Specification: *
>
> The protocol driver calls 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-buffered frame, if the previous
>
> buffer is not the last buffer in the frame it must return the next 
> buffer in the frame in the parameter block. Otherwise it must return 
> the first buffer in the next frame.
>
> Assume the UNDI Driver does not properly Store that TxAddress in the 
> GetStatus then the possibility of MNP Layer having issues when it 
> treats the recycling based on the GetStatus.
>
> 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.
>
> When this point 2 fails the Recycle support done in the SW Layer shall 
> also fail.
>
> Pleases correct my understanding if any .
>
> -Siva
>
> *From:* Rabeda, Maciej [mailto:maciej.rabeda at linux.intel.com]
> *Sent:* Thursday, November 26, 2020 9:10 PM
> *To:* devel at edk2.groups.io; Sivaraman Nainar
> *Subject:* Re: [edk2-devel] reg: PCD To Control MNP Buffer Recycle Support
>
> 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
>
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#68247): https://edk2.groups.io/g/devel/message/68247
Mute This Topic: https://groups.io/mt/78477824/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/edk2-devel-archive/attachments/20201203/aed510a7/attachment.htm>