On Tue, May 22, 2018 at 09:38:13AM -0700, Linus Torvalds wrote:
> On Tue, May 22, 2018 at 2:09 AM Roman Penyaev <
> roman.peny...@profitbricks.com> wrote:
>
> > Should I resend current patch with more clear comments about how careful
> > caller should be with a leaking pointer?
>
> No. Even if
On Tue, May 22, 2018 at 11:09:16AM +0200, Roman Penyaev wrote:
> On Mon, May 21, 2018 at 5:31 PM, Paul E. McKenney
> wrote:
> > On Mon, May 21, 2018 at 03:50:10PM +0200, Roman Penyaev wrote:
> >> On Sun, May 20, 2018 at 2:43 AM, Paul E. McKenney
> >>
On Tue, May 22, 2018 at 2:09 AM Roman Penyaev <
roman.peny...@profitbricks.com> wrote:
> Should I resend current patch with more clear comments about how careful
> caller should be with a leaking pointer?
No. Even if we go your way, there is *one* single user, and that one is
special and needs
On Tue, May 22, 2018 at 11:09:08AM +0200, Roman Penyaev wrote:
> On Mon, May 21, 2018 at 5:33 PM, Paul E. McKenney
> wrote:
> > On Mon, May 21, 2018 at 08:16:59AM -0700, Linus Torvalds wrote:
> >> On Mon, May 21, 2018 at 6:51 AM Roman Penyaev <
> >>
On Mon, May 21, 2018 at 5:31 PM, Paul E. McKenney
wrote:
> On Mon, May 21, 2018 at 03:50:10PM +0200, Roman Penyaev wrote:
>> On Sun, May 20, 2018 at 2:43 AM, Paul E. McKenney
>> wrote:
>> > On Sat, May 19, 2018 at 10:20:48PM +0200, Roman
On Mon, May 21, 2018 at 5:33 PM, Paul E. McKenney
wrote:
> On Mon, May 21, 2018 at 08:16:59AM -0700, Linus Torvalds wrote:
>> On Mon, May 21, 2018 at 6:51 AM Roman Penyaev <
>> roman.peny...@profitbricks.com> wrote:
>>
>> > No, I continue from the pointer, which I
On Mon, May 21, 2018 at 08:16:59AM -0700, Linus Torvalds wrote:
> On Mon, May 21, 2018 at 6:51 AM Roman Penyaev <
> roman.peny...@profitbricks.com> wrote:
>
> > No, I continue from the pointer, which I assigned on the previous IO
> > in order to send IO fairly and keep load balanced.
>
> Right.
On Mon, May 21, 2018 at 03:50:10PM +0200, Roman Penyaev wrote:
> On Sun, May 20, 2018 at 2:43 AM, Paul E. McKenney
> wrote:
> > On Sat, May 19, 2018 at 10:20:48PM +0200, Roman Penyaev wrote:
> >> On Sat, May 19, 2018 at 6:37 PM, Paul E. McKenney
> >>
On Mon, May 21, 2018 at 6:51 AM Roman Penyaev <
roman.peny...@profitbricks.com> wrote:
> No, I continue from the pointer, which I assigned on the previous IO
> in order to send IO fairly and keep load balanced.
Right. And that's exactly what has both me and Paul nervous. You're no
longer in the
On Sun, May 20, 2018 at 2:43 AM, Paul E. McKenney
wrote:
> On Sat, May 19, 2018 at 10:20:48PM +0200, Roman Penyaev wrote:
>> On Sat, May 19, 2018 at 6:37 PM, Paul E. McKenney
>> wrote:
>> > On Fri, May 18, 2018 at 03:03:48PM +0200, Roman
On Sat, May 19, 2018 at 10:20:48PM +0200, Roman Penyaev wrote:
> On Sat, May 19, 2018 at 6:37 PM, Paul E. McKenney
> wrote:
> > On Fri, May 18, 2018 at 03:03:48PM +0200, Roman Pen wrote:
> >> Function is going to be used in transport over RDMA module
> >> in subsequent
On Sat, May 19, 2018 at 1:25 PM Roman Penyaev <
roman.peny...@profitbricks.com> wrote:
> Another one list_for_each_entry_rcu()-like macro I am aware of is used in
> block/blk-mq-sched.c, is called list_for_each_entry_rcu_rr():
On Sat, May 19, 2018 at 1:21 PM Roman Penyaev <
roman.peny...@profitbricks.com> wrote:
> I need -rr behaviour for doing IO load-balancing when I choose next RDMA
> connection from the list in order to send a request, i.e. my code is
> something like the following:
[ incomplete pseudoicode ]
>
On Fri, May 18, 2018 at 6:56 PM, Linus Torvalds
wrote:
> On Fri, May 18, 2018 at 6:07 AM Roman Pen
> wrote:
>
>> Function is going to be used in transport over RDMA module
>> in subsequent patches.
>
> Does this really merit its own
On Sat, May 19, 2018 at 6:37 PM, Paul E. McKenney
wrote:
> On Fri, May 18, 2018 at 03:03:48PM +0200, Roman Pen wrote:
>> Function is going to be used in transport over RDMA module
>> in subsequent patches.
>>
>> Function returns next element in round-robin fashion,
>>
On Fri, May 18, 2018 at 03:03:48PM +0200, Roman Pen wrote:
> Function is going to be used in transport over RDMA module
> in subsequent patches.
>
> Function returns next element in round-robin fashion,
> i.e. head will be skipped. NULL will be returned if list
> is observed as empty.
>
>
On Fri, May 18, 2018 at 6:07 AM Roman Pen
wrote:
> Function is going to be used in transport over RDMA module
> in subsequent patches.
Does this really merit its own helper macro in a generic header?
It honestly smells more like "just have an inline helper
17 matches
Mail list logo