On Wed, 2009-05-27 at 17:11 -0700, Vasu Dev wrote:
>
> Joe you pointed this issue before in response to initial this patch
> series post at
> http://www.open-fcoe.org/pipermail/devel/2009-May/002329.html. I think
> earlier suggested lp check in exch_mgr_reset to solve this issue will
> be
> better solution since that will be more generic being in libfc than
> having each libfc user like fcoe.ko implement reset to handle
> resetting
> of shared OEM and also it will make libfc fully capable of allowing
> shared em across lport/VN_PORTs. I'm working on this fix.
>
> For this fix, I'm working on originally posted series from me instead
> fixing this re-organized patches series for these reasons:-
>
> 1. Some of the combined patches too big to review like this
> patch 3/4
> of this series, 141 insertions(+), 91 deletions(-).
> 2. Keep EM exchange ID allocation patch 4/4 separate from my
> initial
> series doing only work for dedicate shared EM for offload xids, I want
> to focus on this first.
> 3. The initial series already took care of issue around
> offload EM
> addition deletion in re-organized this code series.
>
> However Rob has done good documentation improvements in this
> series and
> I'll try same for my initial post while also collecting applicable all
> feedback discussed in this series to my initial series.
>
> I'm not sure what prompted Rob to re-org initial series post
> than
> addressing discussed comments from
> http://www.open-fcoe.org/pipermail/devel/2009-May/002330.html, I guess
> it was not due to patch count since initial post had moderate logical
> breakup for average approx 60 lines code change per patch in 6 patch
> series. It could be discussed fc_fcp_ddp_setup during last code walk
> through with Rob, the initial series dropped using fc_fcp_ddp_setup in
> first patch and then used it in last patch once dedicated OEM setup
> done
> but that could be fixed by simply not dropping use of fc_fcp_ddp_setup
> in first patch of initial patch series. I'll do that in rework so that
> DDP will be in use for all patches of the series in case DDP
> functionality needs git-bisect in future.
>
> However Rob if you insist to fix from revised series then I'm fine
> with
I should have elaborated here by saying if Rob have good reasons to
resume work from revised 3 patch series then I'm fine resuming work from
this series also instead of simply saying insist, my mistake for wrong
phrasing here.
Also added Rob to TO email addr list.
Vasu
> that as well but for reasons mentioned above I'll prefer to work from
> initial patch series.
_______________________________________________
devel mailing list
[email protected]
http://www.open-fcoe.org/mailman/listinfo/devel
