On Mon, Jan 20, 2014, Or Gerlitz <[email protected]> wrote:
> On Sun, Jan 19, 2014, sagi grimberg <[email protected]> wrote:
>> Thanks Nic, let me elaborate on this,
[...]
>> Hope this helps,
> Hi Roland, with Nic's && Sagi's answers @ hand, were your questions resolved?
Roland, ping! the signature patches were posted > three months ago. We
deserve a response from the maintainer that goes beyond "I need to
think on that".
Responsiveness was stated by Linus to be the #1 requirement from
kernel maintainers.
Or.
On Tue, Jan 21, 2014 at 2:00 PM, Or Gerlitz <[email protected]> wrote:
> Roland, ping! the signature patches were posted > three months ago. We
> deserve a response from the maintainer that goes beyond "I need to
> think on that".
>
> Responsiveness was stated by Linus to be the #1 requirement from
> kernel maintainers.
Or, I'm not sure what response you're after from me. Linus has also
said that maintainers should say "no" a lot more
(http://lwn.net/Articles/571995/) so maybe you want me to say, "No, I
won't merge this patch set, since it adds a bunch of complexity to
support a feature no one really cares about." Is that it? (And yes I
am skeptical about this stuff ? I work at an enterprise storage
company and even here it's hard to find anyone who cares about
DIF/DIX, especially offload features that stop it from being
end-to-end)
I'm sure you're not expecting me to say, "Sure, I'll merge it without
understanding the problem it's solving or how it's doing that,"
especially given the your recent history of pushing me to merge stuff
like the IP-RoCE patches back when they broke the userspace ABI.
I'd really rather spend my time on something actually useful like
cleaning up softroce.
- R.
On Wed, Jan 22, 2014 at 2:43 AM, Roland Dreier <[email protected]> wrote:
> On Tue, Jan 21, 2014 at 2:00 PM, Or Gerlitz <[email protected]> wrote:
>> Roland, ping! the signature patches were posted > three months ago. We
>> deserve a response from the maintainer that goes beyond "I need to
>> think on that".
>>
>> Responsiveness was stated by Linus to be the #1 requirement from
>> kernel maintainers.
>
> Or, I'm not sure what response you're after from me.
Roland, what I am after is a r-e-s-p-o-n-s-e from you, and let it
contain what ever justified and/or unjustified mud as below. We posted
the V0 series on Oct 15 2013 and since that time not a word from you,
except for an "I need to think on that" comment last week after we
nudged million times.
You can't leave us clueless in the air for whole three months without
any concrete or unconcrete comment. There's no way to carry kernel
development like that. I am old enough to hear and face "no" and "wTF
is this" or "yTF you do it this way" etc etc, this happened few times
with e.g with networking patches we sent and we either improved
things or did them differently or whatever needed to be done.
There's no way on earth to face plain ignoring of your work, and this
is what happens here. I had no way to get your below response except
for going to LKML, why?
> Linus has also said that maintainers should say "no" a lot more
> (http://lwn.net/Articles/571995/) so maybe you want me to say, "No, I
> won't merge this patch set, since it adds a bunch of complexity to
> support a feature no one really cares about." Is that it? (And yes I
> am skeptical about this stuff ? I work at an enterprise storage
> company and even here it's hard to find anyone who cares about
> DIF/DIX, especially offload features that stop it from being
> end-to-end)
>
> I'm sure you're not expecting me to say, "Sure, I'll merge it without
> understanding the problem it's solving or how it's doing that,"
> especially given the your recent history of pushing me to merge stuff
> like the IP-RoCE patches back when they broke the userspace ABI.
>
> I'd really rather spend my time on something actually useful like
> cleaning up softroce.
>
> - R.
Roland & Co,
On Tue, 2014-01-21 at 16:43 -0800, Roland Dreier wrote:
> On Tue, Jan 21, 2014 at 2:00 PM, Or Gerlitz <[email protected]> wrote:
> > Roland, ping! the signature patches were posted > three months ago. We
> > deserve a response from the maintainer that goes beyond "I need to
> > think on that".
> >
> > Responsiveness was stated by Linus to be the #1 requirement from
> > kernel maintainers.
>
> Or, I'm not sure what response you're after from me. Linus has also
> said that maintainers should say "no" a lot more
> (http://lwn.net/Articles/571995/) so maybe you want me to say, "No, I
> won't merge this patch set, since it adds a bunch of complexity to
> support a feature no one really cares about." Is that it?
The patch set proposed by Sagi + Or is modest in terms of LOC to core IB
code, and includes mostly mlx5 specific driver changes that enables HW
offloads.
> (And yes I
> am skeptical about this stuff — I work at an enterprise storage
> company and even here it's hard to find anyone who cares about
> DIF/DIX, especially offload features that stop it from being
> end-to-end)
>
My understanding is most HBAs capable of T10 PI offload in DIX PASS +
VERIFY mode are already implementing DIX INSERT + STRIP modes in various
capacities to support legacy environments.
Beyond the DIX INSERT + STRIP case for enterprise storage, the amount of
FC + SAS HBAs that already support T10 PI metadata is substantial.
> I'm sure you're not expecting me to say, "Sure, I'll merge it without
> understanding the problem it's solving or how it's doing that,"
> especially given the your recent history of pushing me to merge stuff
> like the IP-RoCE patches back when they broke the userspace ABI.
With the merge window now upon us, there is a understandable reluctance
to merge new features. Given the amount of time the series has spent on
the list, it is however a good candidate to consider for an exception.
Short of that, are you planning to accept the series for the next round
once the current merge window closes..?
We'd really like to start enabling fabrics with these types of offloads
for v3.15.
> I'd really rather spend my time on something actually useful like
> cleaning up softroce.
>
+1 for softroce + T10 PI support!
--nab
Hi Roland,
On Tue, 2014-01-21 at 23:27 -0800, Nicholas A. Bellinger wrote:
> Roland & Co,
>
> On Tue, 2014-01-21 at 16:43 -0800, Roland Dreier wrote:
> > On Tue, Jan 21, 2014 at 2:00 PM, Or Gerlitz <[email protected]> wrote:
> > > Roland, ping! the signature patches were posted > three months ago. We
> > > deserve a response from the maintainer that goes beyond "I need to
> > > think on that".
> > >
> > > Responsiveness was stated by Linus to be the #1 requirement from
> > > kernel maintainers.
> >
> > Or, I'm not sure what response you're after from me. Linus has also
> > said that maintainers should say "no" a lot more
> > (http://lwn.net/Articles/571995/) so maybe you want me to say, "No, I
> > won't merge this patch set, since it adds a bunch of complexity to
> > support a feature no one really cares about." Is that it?
>
> The patch set proposed by Sagi + Or is modest in terms of LOC to core IB
> code, and includes mostly mlx5 specific driver changes that enables HW
> offloads.
>
> > (And yes I
> > am skeptical about this stuff — I work at an enterprise storage
> > company and even here it's hard to find anyone who cares about
> > DIF/DIX, especially offload features that stop it from being
> > end-to-end)
> >
>
> My understanding is most HBAs capable of T10 PI offload in DIX PASS +
> VERIFY mode are already implementing DIX INSERT + STRIP modes in various
> capacities to support legacy environments.
>
> Beyond the DIX INSERT + STRIP case for enterprise storage, the amount of
> FC + SAS HBAs that already support T10 PI metadata is substantial.
>
> > I'm sure you're not expecting me to say, "Sure, I'll merge it without
> > understanding the problem it's solving or how it's doing that,"
> > especially given the your recent history of pushing me to merge stuff
> > like the IP-RoCE patches back when they broke the userspace ABI.
>
> With the merge window now upon us, there is a understandable reluctance
> to merge new features. Given the amount of time the series has spent on
> the list, it is however a good candidate to consider for an exception.
>
> Short of that, are you planning to accept the series for the next round
> once the current merge window closes..?
>
> We'd really like to start enabling fabrics with these types of offloads
> for v3.15.
>
Now with the initial DIF backend taraget support in place for v3.14-rc1
code, we'd like to move forward on iser-target related pieces for T10
PI.
Can you give us an estimate of when you'll have some time to give
feedback on the outstanding patches..?
--nab
On Thu, Feb 6, 2014 at 4:02 PM, Nicholas A. Bellinger
<[email protected]> wrote:
> Can you give us an estimate of when you'll have some time to give
> feedback on the outstanding patches..?
I hope to get to it in the next few weeks.
- R.
On Fri, Feb 7, 2014 at 2:04 AM, Roland Dreier <[email protected]> wrote:
> On Thu, Feb 6, 2014 at 4:02 PM, Nicholas A. Bellinger
> <[email protected]> wrote:
>> Can you give us an estimate of when you'll have some time to give
>> feedback on the outstanding patches..?
>
> I hope to get to it in the next few weeks.
Hi Roland,
So days, weeks and months are passing by and we still didn't get any
real feedback from you on the patches which now make a complete story:
verbs, driver, target and initiator nor on the detailed response/s
sent to you as replies to the few on the surface quick questions and
doubts you raised. 3.15 is coming soon and there's no reason to miss
it just for that lack of feedback as happened for 3.13 and 3.14 -- are
you picking on this or maybe prefer that Nic will push it upstream
through his tree? all the patches are now on the rdma-dif of the
target-pending tree, please let us know.
>
> - R.