From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from IMSVA.IN.MEGATRENDS.COM (IMSVA.IN.MEGATRENDS.COM [14.98.235.2]) by mx.groups.io with SMTP id smtpd.web08.7298.1606407653441562386 for ; Thu, 26 Nov 2020 08:20:54 -0800 Authentication-Results: mx.groups.io; dkim=missing; spf=none, err=SPF record not found (domain: amiindia.co.in, ip: 14.98.235.2, mailfrom: sivaramann@amiindia.co.in) Received: from IMSVA.IN.MEGATRENDS.COM (IMSVA.IN.MEGATRENDS.COM [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 1A06782047; Thu, 26 Nov 2020 22:00:09 +0530 (IST) Received: from IMSVA.IN.MEGATRENDS.COM (IMSVA.IN.MEGATRENDS.COM [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 0EF6482046; Thu, 26 Nov 2020 22:00:06 +0530 (IST) Received: from webmail.amiindia.co.in (venus2.in.megatrends.com [10.0.0.7]) by IMSVA.IN.MEGATRENDS.COM (Postfix) with ESMTPS; Thu, 26 Nov 2020 22:00:06 +0530 (IST) Received: from VENUS1.in.megatrends.com ([fe80::951:7975:6ecf:eae5]) by Venus2.in.megatrends.com ([fe80::2002:4a07:4f17:c09b%14]) with mapi id 14.03.0248.002; Thu, 26 Nov 2020 21:50:45 +0530 From: "Sivaraman Nainar" To: "Rabeda, Maciej" , "devel@edk2.groups.io" Subject: Re: [edk2-devel] reg: PCD To Control MNP Buffer Recycle Support Thread-Topic: [edk2-devel] reg: PCD To Control MNP Buffer Recycle Support Thread-Index: AdbCbeWThzYx1AsoTICtWUYaJ+VlaQBbmVGAAAzRkzA= Date: Thu, 26 Nov 2020 16:20:43 +0000 Message-ID: References: <78af7771-8edf-ec2b-9db4-92ad9f506380@linux.intel.com> In-Reply-To: <78af7771-8edf-ec2b-9db4-92ad9f506380@linux.intel.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.3.115] MIME-Version: 1.0 X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.1.0.1817-8.6.0.1013-25814.001 X-TM-AS-Result: No--8.152-5.0-31-10 X-imss-scan-details: No--8.152-5.0-31-10 X-TMASE-Version: IMSVA-9.1.0.1817-8.6.1013-25814.001 X-TMASE-Result: 10--8.152200-10.000000 X-TMASE-MatchedRID: vWvnoyq7eMxbJCKOm3VRCYrUOsGJRfY94MZEpBAfSmJGjk/QOKmZVTMf zAbQT02PbwFT1cZHxCGEv01fZOqaQA51SAUUhKsUVI7KaIl9NhctzfxwxXxboal9ZYCuwx6opQR JeFoGUm9YwMQSR3qB3dADrbIPlTXHrP7zBZ710YYBVCYidVqVZG/62KJeirU1TjhVAkZR7rEwM6 XxbfFDF0W9nOUq6AmALyz9QvAyHjqlGCIMbr7g/mOMyb1Ixq8VlaLGcPEXs1Aa3/PSrtM/hIznV iRE4fC+aBevM/eurMdqZ6OipRp3el0DithooYrCzVgwP7ZMYf8WAPp8Oey6LIYvWj7gxgwiw+Tc 8yW63+5Muo0RGtLUa+NI3Mct2lza9+PHtghP8GKZt08TfNy6OLsnAPikIQ0UtL1JV4RAlPvYlAh rLW5bRu9e8ifCHArb0H8ihGEHNUcsCc2iFTIxrf9LEanWbLZ2ZCxbT73Ur4iZPojpBjTiHJiNwi 0+6slunz66/vAHyxPnh6rB4tZovgYAPqHoVmYRXjbObVmL4wkJwCwp3rkHhc7m5g7Op40tQUm5i Q93axUThoSda/5QgpTaJnWciFiifrTt+hmA5bLvJUJocp0YsXSV0icsLWG5NtrqBJtuOX5YFBU0 +2PUKWE2dpl/p8cMG66tuBin4dDaCn4DqCiXNozGYa2TUZhfdUC3hOI/cuLtRjRvIHwGKtRLDuP lzIVLPD4d8ZrUDDN+mObOePntysHDWBf/LgJ8SnXYhdlqPHnZNpe4t6HOM0cN36UB4MN7l+soBK tnVK3f8QWOo2ap2UUfqhOIibCHqGj+YxBQdJibKItl61J/yZUdXE/WGn0FHwAqApZ40aESsYwLh H7g0dbkrsq6X+Ue09CawzHu+W1xDLXB1megc99q1Q6HFHEMmZPHYzJYSdHGA0iBk14xoAwS0WAe 30kPcQQxy3c2QW749mbQX9J1EM7unBR8Z1sSEDp99vCZDYlDDKa3G4nrLQ== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_B4DE137BDB63634BAC03BD9DE765F19702B4B9D428VENUS1inmegat_" --_000_B4DE137BDB63634BAC03BD9DE765F19702B4B9D428VENUS1inmegat_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 re= ceived 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 buf= fer in the next frame. Assume the UNDI Driver does not properly Store that TxAddress in the GetSt= atus then the possibility of MNP Layer having issues when it treats the rec= ycling based on the GetStatus. 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 appropria= te region. UNDI driver should also store that Tx buffer somewhere within th= e driver, where it will be accessible by UNDI->GetStatus() function. When this point 2 fails the Recycle support done in the SW Layer shall als= o fail. Pleases correct my understanding if any . -Siva From: Rabeda, Maciej [mailto:maciej.rabeda@linux.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 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) 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 appropria= te region. UNDI driver should also store that Tx buffer somewhere within th= e 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 buffe= r 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 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 from the below git commit= , https://github.com/tianocore/edk2/commit/0507449955c5c629cec196b62986afbb9= 1203ed9#diff-fb5b97ad38efea22f5ddd745f6e43ebdb509dc4a5aef81997ba53af5f918a4= 7b But many network controllers does not support the Recycling Tx Buffers whi= ch 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 --_000_B4DE137BDB63634BAC03BD9DE765F19702B4B9D428VENUS1inmegat_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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

 

--_000_B4DE137BDB63634BAC03BD9DE765F19702B4B9D428VENUS1inmegat_--