Re: [PATCH v2 14/26] ibtrs: include client and server modules into kernel compilation

On Tue, May 22, 2018 at 3:18 PM, Leon Romanovsky <l...@kernel.org> wrote: > On Tue, May 22, 2018 at 11:27:21AM +0200, Roman Penyaev wrote: >> On Tue, May 22, 2018 at 7:05 AM, Leon Romanovsky <l...@kernel.org> wrote: >> > On Fri, May 18, 2018 at 03:04:01PM +0200, Ro

Re: [PATCH v2 14/26] ibtrs: include client and server modules into kernel compilation

On Tue, May 22, 2018 at 7:05 AM, Leon Romanovsky wrote: > On Fri, May 18, 2018 at 03:04:01PM +0200, Roman Pen wrote: >> Add IBTRS Makefile, Kconfig and also corresponding lines into upper >> layer infiniband/ulp files. >> >> Signed-off-by: Roman Pen

Re: [PATCH v2 01/26] rculist: introduce list_next_or_null_rr_rcu()

On Mon, May 21, 2018 at 5:31 PM, Paul E. McKenney <paul...@linux.vnet.ibm.com> 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 >> <paul...@linux.vnet.ibm.com> wrote: >> > On Sat, May

Re: [PATCH v2 01/26] rculist: introduce list_next_or_null_rr_rcu()

On Mon, May 21, 2018 at 5:33 PM, Paul E. McKenney <paul...@linux.vnet.ibm.com> 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: >> >> >

Re: [PATCH v2 01/26] rculist: introduce list_next_or_null_rr_rcu()

On Sun, May 20, 2018 at 2:43 AM, Paul E. McKenney <paul...@linux.vnet.ibm.com> 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 >> <paul...@linux.vnet.ibm.com> wrote: >> > On Fri, May

Re: [PATCH v2 01/26] rculist: introduce list_next_or_null_rr_rcu()

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

Re: [PATCH v2 01/26] rculist: introduce list_next_or_null_rr_rcu()

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, >>

Re: [PATCH 00/24] InfiniBand Transport (IBTRS) and Network Block Device (IBNBD)

On Wed, Feb 7, 2018 at 5:35 PM, Christopher Lameter wrote: > On Mon, 5 Feb 2018, Bart Van Assche wrote: > >> That approach may work well for your employer but sorry I don't think this is >> sufficient for an upstream driver. I think that most users who configure a >> network

Re: [PATCH 00/24] InfiniBand Transport (IBTRS) and Network Block Device (IBNBD)

Hi Sagi and all, On Mon, Feb 5, 2018 at 1:30 PM, Sagi Grimberg wrote: > Hi Roman and the team (again), replying to my own email :) > > I forgot to mention that first of all thank you for upstreaming > your work! I fully support your goal to have your production driver >

Re: [PATCH 00/24] InfiniBand Transport (IBTRS) and Network Block Device (IBNBD)

On Tue, Feb 6, 2018 at 5:01 PM, Bart Van Assche <bart.vanass...@wdc.com> wrote: > On Tue, 2018-02-06 at 14:12 +0100, Roman Penyaev wrote: >> On Mon, Feb 5, 2018 at 1:16 PM, Sagi Grimberg <s...@grimberg.me> wrote: >> > [ ... ] >> > - srp/scst comparison

Re: [PATCH 03/24] ibtrs: core: lib functions shared between client and server modules

On Tue, Feb 6, 2018 at 5:10 PM, Jason Gunthorpe <j...@ziepe.ca> wrote: > On Tue, Feb 06, 2018 at 01:01:23PM +0100, Roman Penyaev wrote: > >> >> +static int ibtrs_ib_dev_init(struct ibtrs_ib_dev *d, struct ib_device >> >> *dev) >> >> +{ &g

Re: [PATCH 00/24] InfiniBand Transport (IBTRS) and Network Block Device (IBNBD)

Hi Sagi, On Mon, Feb 5, 2018 at 1:16 PM, Sagi Grimberg wrote: > Hi Roman and the team, > > On 02/02/2018 04:08 PM, Roman Pen wrote: >> >> This series introduces IBNBD/IBTRS modules. >> >> IBTRS (InfiniBand Transport) is a reliable high speed transport library >> which allows

Re: [PATCH 09/24] ibtrs: server: main functionality

d Transport Layer >> + * >> + * Copyright (c) 2014 - 2017 ProfitBricks GmbH. All rights reserved. >> + * Authors: Fabian Holler <m...@fholler.de> >> + * Jack Wang <jinpu.w...@profitbricks.com> >> + * Kleber Souza <kleber.so...@profitb

Re: [PATCH 07/24] ibtrs: client: sysfs interface functions

On Mon, Feb 5, 2018 at 12:20 PM, Sagi Grimberg wrote: > Hi Roman, > > >> This is the sysfs interface to IBTRS sessions on client side: >> >>/sys/kernel/ibtrs_client// >> *** IBTRS session created by ibtrs_clt_open() API call >> | >> |- max_reconnect_attempts

Re: [PATCH 04/24] ibtrs: client: private header with client structs and functions

Hi Sagi, On Mon, Feb 5, 2018 at 11:59 AM, Sagi Grimberg wrote: > Hi Roman, > > >> +struct ibtrs_clt_io_req { >> + struct list_headlist; >> + struct ibtrs_iu *iu; >> + struct scatterlist *sglist; /* list holding user data */ >> +

Re: [PATCH 03/24] ibtrs: core: lib functions shared between client and server modules

Hi Sagi, On Mon, Feb 5, 2018 at 11:52 AM, Sagi Grimberg wrote: > Hi Roman, > > Here are some comments below. > >> +int ibtrs_post_recv_empty(struct ibtrs_con *con, struct ib_cqe *cqe) >> +{ >> + struct ib_recv_wr wr, *bad_wr; >> + >> + wr.next= NULL; >> +

Re: [PATCH 00/24] InfiniBand Transport (IBTRS) and Network Block Device (IBNBD)

On Mon, Feb 5, 2018 at 6:20 PM, Bart Van Assche <bart.vanass...@wdc.com> wrote: > On Mon, 2018-02-05 at 18:16 +0100, Roman Penyaev wrote: >> Everything (fio jobs, setup, etc) is given in the same link: >> >> https://www.spinics.net/lists/linux-rdma/msg48799.html >&g

Re: [PATCH 00/24] InfiniBand Transport (IBTRS) and Network Block Device (IBNBD)

Hi Bart, On Mon, Feb 5, 2018 at 5:58 PM, Bart Van Assche wrote: > On Mon, 2018-02-05 at 14:16 +0200, Sagi Grimberg wrote: >> - Your latency measurements are surprisingly high for a null target >>device (even for low end nvme device actually) regardless of the >>

Re: [PATCH 05/24] ibtrs: client: main functionality

On Mon, Feb 5, 2018 at 3:14 PM, Sagi Grimberg wrote: > >> Indeed, seems sbitmap can be reused. >> >> But tags is a part of IBTRS, and is not related to block device at all. >> One >> IBTRS connection (session) handles many block devices > > > we use host shared tag sets for the

Re: [PATCH 05/24] ibtrs: client: main functionality

Hi Sagi, On Mon, Feb 5, 2018 at 12:19 PM, Sagi Grimberg wrote: > Hi Roman, > >> +static inline void ibtrs_clt_state_lock(void) >> +{ >> + rcu_read_lock(); >> +} >> + >> +static inline void ibtrs_clt_state_unlock(void) >> +{ >> + rcu_read_unlock(); >> +} > > > This

Re: [PATCH 05/24] ibtrs: client: main functionality

On Fri, Feb 2, 2018 at 5:54 PM, Bart Van Assche wrote: > On Fri, 2018-02-02 at 15:08 +0100, Roman Pen wrote: >> +static inline struct ibtrs_tag * >> +__ibtrs_get_tag(struct ibtrs_clt *clt, enum ibtrs_clt_con_type con_type) >> +{ >> + size_t max_depth =

Re: [PATCH 23/24] ibnbd: a bit of documentation

On Fri, Feb 2, 2018 at 4:55 PM, Bart Van Assche wrote: > On Fri, 2018-02-02 at 15:09 +0100, Roman Pen wrote: >> +Entries under /sys/kernel/ibnbd_client/ >> +=== >> [ ... ] > > You will need Greg KH's permission to add new entries

Re: [PATCH 16/24] ibnbd: client: main functionality

On Fri, Feb 2, 2018 at 4:11 PM, Jens Axboe wrote: > On 2/2/18 7:08 AM, Roman Pen wrote: >> This is main functionality of ibnbd-client module, which provides >> interface to map remote device as local block device /dev/ibnbd >> and feeds IBTRS with IO requests. > > Kill the legacy

Re: [PATCH V2 0/2] block: remove unnecessary RESTART

On Mon, Oct 30, 2017 at 9:33 PM, Bart Van Assche <bart.vanass...@wdc.com> wrote: > On Fri, 2017-10-27 at 19:55 +0200, Roman Penyaev wrote: >> That's just a bug in code, not a in issue with restarts, which can be fixed >> if we put hctx which are needed to be restarted in p

Re: [PATCH 1/1] [RFC] blk-mq: fix queue stalling on shared hctx restart

Hi Ming, On Fri, Oct 20, 2017 at 3:39 PM, Ming Lei wrote: > On Wed, Oct 18, 2017 at 12:22:06PM +0200, Roman Pen wrote: >> Hi all, >> >> the patch below fixes queue stalling when shared hctx marked for restart >> (BLK_MQ_S_SCHED_RESTART bit) but q->shared_hctx_restart stays

Re: [PATCH 1/1] [RFC] blk-mq: fix queue stalling on shared hctx restart

On Fri, Oct 20, 2017 at 10:05 PM, Bart Van Assche <bart.vanass...@wdc.com> wrote: > On Fri, 2017-10-20 at 11:39 +0200, Roman Penyaev wrote: >> But what bothers me is these looong loops inside blk_mq_sched_restart(), >> and since you are the author of the original 6d8c6c0f9

Re: [PATCH 1/1] [RFC] blk-mq: fix queue stalling on shared hctx restart

Hi Bart, On Thu, Oct 19, 2017 at 7:47 PM, Bart Van Assche wrote: > On Wed, 2017-10-18 at 12:22 +0200, Roman Pen wrote: >> the patch below fixes queue stalling when shared hctx marked for restart >> (BLK_MQ_S_SCHED_RESTART bit) but q->shared_hctx_restart stays zero. The

Re: RDMA performance comparison: IBNBD, SCST, NVMEoF

Hello Bart, On Tue, Apr 18, 2017 at 8:22 PM, Bart Van Assche <bart.vanass...@sandisk.com> wrote: > On Tue, 2017-04-18 at 19:33 +0200, Roman Penyaev wrote: >> By current email I would like to share some fresh RDMA performance >> results of IBNBD, SCST and NVMEof, based on 4.

RDMA performance comparison: IBNBD, SCST, NVMEoF

Hi Bart, Sagi and all, By current email I would like to share some fresh RDMA performance results of IBNBD, SCST and NVMEof, based on 4.10 kernel and variety of configurations. All fio runs are grouped by the name of a project, crucial config differencies (e.g. CPU pinning or register_always=N)

Re: [RFC PATCH 00/28] INFINIBAND NETWORK BLOCK DEVICE (IBNBD)

Hi Bart and Sagi, Thanks for warm welcome and early feedback. I will respond both of you but here, on Jack's email, since I am not in CC in the first cover letter (what a bummer). Sorry for mess. Sagi Grimberg wrote: > - Is there room for this ibnbd? If we were to take

Re: [PATCH v2 1/1] blk-mq: fix hang caused by freeze/unfreeze sequence

On Wed, Aug 10, 2016 at 10:42 AM, Roman Penyaev <roman.peny...@profitbricks.com> wrote: > Hi, > > On Wed, Aug 10, 2016 at 5:55 AM, Tejun Heo <t...@kernel.org> wrote: >> Hello, >> >> On Mon, Aug 08, 2016 at 01:39:08PM +0200, Roman Pen wrote: >>>