From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by mx.groups.io with SMTP id smtpd.web12.6823.1606405209270636723 for ; Thu, 26 Nov 2020 07:40:09 -0800 Authentication-Results: mx.groups.io; dkim=missing; spf=none, err=permanent DNS error (domain: linux.intel.com, ip: 192.55.52.136, mailfrom: maciej.rabeda@linux.intel.com) IronPort-SDR: ADvlD+Sam1CTAuM7XWvg8+AISBZSReBix5j4ERQ4/uoZbAkztdtV/lUlRg05OvTyAUj/JRCTp6 Pz9mBtt+vXiA== X-IronPort-AV: E=McAfee;i="6000,8403,9817"; a="151555070" X-IronPort-AV: E=Sophos;i="5.78,372,1599548400"; d="scan'208,217";a="151555070" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Nov 2020 07:40:05 -0800 IronPort-SDR: 4lLfWdOQRjBCdh57nFjwWNLyeIEGzE7bEbzV/OK+FqgZ5vmOJyIsHnBKrdMV3bpv0B7FA5QgKR egIWWRNSTyXQ== X-IronPort-AV: E=Sophos;i="5.78,372,1599548400"; d="scan'208,217";a="537344527" Received: from mrabeda-mobl.ger.corp.intel.com (HELO [10.213.26.1]) ([10.213.26.1]) by fmsmga005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Nov 2020 07:40:04 -0800 Subject: Re: [edk2-devel] reg: PCD To Control MNP Buffer Recycle Support To: devel@edk2.groups.io, sivaramann@amiindia.co.in References: From: "Maciej Rabeda" Message-ID: <78af7771-8edf-ec2b-9db4-92ad9f506380@linux.intel.com> Date: Thu, 26 Nov 2020 16:39:57 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------FA9DD812C210A21733DD182B" Content-Language: pl --------------FA9DD812C210A21733DD182B Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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 > > > 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 > > --------------FA9DD812C210A21733DD182B Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit 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

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

--------------FA9DD812C210A21733DD182B--