public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Wu, Jiaxin" <jiaxin.wu@intel.com>
To: Laszlo Ersek <lersek@redhat.com>,
	"edk2-devel@lists.01.org" <edk2-devel@lists.01.org>
Cc: "Ye, Ting" <ting.ye@intel.com>,
	"Carsey, Jaben" <jaben.carsey@intel.com>,
	 "Fu, Siyuan" <siyuan.fu@intel.com>,
	"Shao, Ming" <ming.shao@intel.com>,
	"Li, Ruth" <ruth.li@intel.com>
Subject: Re: [Patch 0/5] Support windowsize to benefit tftp/pxe download performance.
Date: Fri, 21 Sep 2018 06:33:39 +0000	[thread overview]
Message-ID: <895558F6EA4E3B41AC93A00D163B7274164A3660@SHSMSX103.ccr.corp.intel.com> (raw)
In-Reply-To: <845df55b-b9ba-20f9-25fd-22778253c198@redhat.com>

Hi Laszlo,

> 
> If that's the case, should we consider the three drivers under
> "MdeModulePkg/Universal/Network/" deprecated, and should we abandon
> them
> completely?
> 


I think the answer is NO (At least for now). In my opinion, the drivers in MdeModulePkg is also useful in some case, because it already has been used in some platform since it's lightweight to reduce the platform size requirement. As you said below, there is no openssl dependency in MdeModulePkg/ISCSI. 



> If that's the case, then it is really important to document.
> 
> Because, if a user reports a networking-related error (after building
> OVMF without NETWORK_IP6_ENABLE), then I wouldn't like to start
> investigating, just to find out that the issue was fixed in NetworkPkg a
> year earlier.
> 
> Furthermore, if the MdeModulePkg/Universal/Network/ drivers are
> deprecated, when do we intend to actually remove them from the tree?
> 
> Oh, wait, is this related to OpenSSL? When including IScsiDxe from
> NetworkPkg, OpenSSL is required. When including IScsiDxe from
> MdeModulePkg, OpenSSL is not required -- but the networking
> functionality may have some known bugs (which are already fixed in
> NetworkPkg).
> 
> Is this the real trade-off?
> 

For the missed fixes, that's because we didn't take a look whether it also existed in MdeModulePkg, you know, some issues need to be analyzed case by case and most of them are usage related, but actually, it's not so such critical to the other platform. That's why we prefer/try to stay the same of those drivers in MdeModulePkg, if so, it also can help us reduce the development/testing effort against two sets of stacks. What we prefer is to fix the problem / include new feature separately. As I said before, depends on the request/report from customer. So, that's the reason why we recommend to use the stacks in NetworkPkg. Of Couse, if any issue was exposed in MdeModulePkg, we will help to investigate and fix it.

I agree we need document something to highlight that. Siyuan/Ting, if no objection, I will do that in separate patch instead of mixing with this new feature support.


Thanks
Jiaxin




  parent reply	other threads:[~2018-09-21  6:35 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-17  5:43 [Patch 0/5] Support windowsize to benefit tftp/pxe download performance Jiaxin Wu
2018-09-17  5:43 ` [Patch 1/5] MdeModulePke/Mtftp4Dxe: Support windowsize in read request operation Jiaxin Wu
2018-09-17  5:43 ` [Patch 2/5] NetworkPkg/Mtftp6Dxe: " Jiaxin Wu
2018-09-17  5:43 ` [Patch 3/5] ShellPkg/TftpDynamicCommand: Add one option for tftp command to specify windowsize Jiaxin Wu
2018-09-17 22:18   ` Carsey, Jaben
2018-09-17  5:43 ` [Patch 4/5] MdeModulePkg/MdeModulePkg.dec: Define one PCD for PXE to specify MTFTP windowsize Jiaxin Wu
2018-09-18 11:04   ` Laszlo Ersek
2018-09-19  1:55     ` Wu, Jiaxin
2018-09-19  0:38   ` Fu, Siyuan
2018-09-19  2:21     ` Wu, Jiaxin
2018-09-17  5:43 ` [Patch 5/5] NetworkPkg/UefiPxeBcDxe: Use the specified " Jiaxin Wu
2018-09-18 11:23 ` [Patch 0/5] Support windowsize to benefit tftp/pxe download performance Laszlo Ersek
2018-09-19  2:20   ` Wu, Jiaxin
2018-09-19 11:24     ` Laszlo Ersek
2018-09-20  5:54       ` Wu, Jiaxin
     [not found]         ` <845df55b-b9ba-20f9-25fd-22778253c198@redhat.com>
2018-09-21  6:33           ` Wu, Jiaxin [this message]
2018-09-21  9:37             ` Laszlo Ersek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=895558F6EA4E3B41AC93A00D163B7274164A3660@SHSMSX103.ccr.corp.intel.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox