* Re: [PATCH] uio: add UIO_MEM_CUSTOM support [not found] <1487133786-25545-1-git-send-email-lixiubo@cmss.chinamobile.com> @ 2017-02-15 17:19 ` Greg KH 2017-02-16 1:34 ` Xiubo Li 0 siblings, 1 reply; 5+ messages in thread From: Greg KH @ 2017-02-15 17:19 UTC (permalink / raw) To: lixiubo; +Cc: agrover, mchristi, namei.unix, linux-kernel On Wed, Feb 15, 2017 at 12:43:06PM +0800, lixiubo@cmss.chinamobile.com wrote: > From: Xiubo Li <lixiubo@cmss.chinamobile.com> > > This will allow UIO based drivers, like TCMU, have opportunities to > implement their own mmap magics. > > Signed-off-by: Xiubo Li <lixiubo@cmss.chinamobile.com> > --- > drivers/uio/uio.c | 2 ++ > include/linux/uio_driver.h | 1 + > 2 files changed, 3 insertions(+) > > diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c > index fba021f..6ca0ae0 100644 > --- a/drivers/uio/uio.c > +++ b/drivers/uio/uio.c > @@ -708,6 +708,8 @@ static int uio_mmap(struct file *filep, struct vm_area_struct *vma) > case UIO_MEM_LOGICAL: > case UIO_MEM_VIRTUAL: > return uio_mmap_logical(vma); > + case UIO_MEM_CUSTOM: > + return 0; How does this help? Can you provide an update to the documentation in Documentation/driver-api/uio-howto.rst to show how to use this? thanks, greg k-h ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] uio: add UIO_MEM_CUSTOM support 2017-02-15 17:19 ` [PATCH] uio: add UIO_MEM_CUSTOM support Greg KH @ 2017-02-16 1:34 ` Xiubo Li 2017-02-16 5:01 ` Andy Grover 0 siblings, 1 reply; 5+ messages in thread From: Xiubo Li @ 2017-02-16 1:34 UTC (permalink / raw) To: Greg KH; +Cc: agrover, mchristi, namei.unix, linux-kernel >> diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c >> index fba021f..6ca0ae0 100644 >> --- a/drivers/uio/uio.c >> +++ b/drivers/uio/uio.c >> @@ -708,6 +708,8 @@ static int uio_mmap(struct file *filep, struct vm_area_struct *vma) >> case UIO_MEM_LOGICAL: >> case UIO_MEM_VIRTUAL: >> return uio_mmap_logical(vma); >> + case UIO_MEM_CUSTOM: >> + return 0; > How does this help? For example, the TCMU will use the map area as ISCSI commands & data ring buffer(uio0 --> map0). Currently the TCMU will using the fixed small size map area as the ring buffer, but this will be the bottleneck for high iops. Without knowing how large it is enough, so the new scheme will use the fixed small ring buffer area(about 64M ~ 128M) + dynamically "growing" ring buffer area(about 1.5G). The fixed small area will be using vmalloc() when initializing, and dynamically "growing" area will must use kmalloc() for some reasons. ... > Can you provide an update to the documentation in > Documentation/driver-api/uio-howto.rst to show how to use this? Yes, I will update this. Thanks. BRs Xiubo > thanks, > > greg k-h ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] uio: add UIO_MEM_CUSTOM support 2017-02-16 1:34 ` Xiubo Li @ 2017-02-16 5:01 ` Andy Grover 2017-02-16 5:33 ` Xiubo Li 2017-02-16 6:49 ` Xiubo Li 0 siblings, 2 replies; 5+ messages in thread From: Andy Grover @ 2017-02-16 5:01 UTC (permalink / raw) To: Xiubo Li, Greg KH; +Cc: mchristi, namei.unix, linux-kernel On 02/15/2017 05:34 PM, Xiubo Li wrote: >>> --- a/drivers/uio/uio.c >>> +++ b/drivers/uio/uio.c >>> @@ -708,6 +708,8 @@ static int uio_mmap(struct file *filep, struct >>> vm_area_struct *vma) >>> case UIO_MEM_LOGICAL: >>> case UIO_MEM_VIRTUAL: >>> return uio_mmap_logical(vma); >>> + case UIO_MEM_CUSTOM: >>> + return 0; >> How does this help? > For example, the TCMU will use the map area as ISCSI commands & data ring > buffer(uio0 --> map0). Currently the TCMU will using the fixed small > size map > area as the ring buffer, but this will be the bottleneck for high iops. > > Without knowing how large it is enough, so the new scheme will use the > fixed > small ring buffer area(about 64M ~ 128M) + dynamically "growing" ring > buffer > area(about 1.5G). The following code is in uio_mmap() in uio.c: if (idev->info->mmap) { ret = idev->info->mmap(idev->info, vma); return ret; } switch (idev->info->mem[mi].memtype) { case UIO_MEM_PHYS: return uio_mmap_physical(vma); case UIO_MEM_LOGICAL: case UIO_MEM_VIRTUAL: return uio_mmap_logical(vma); default: return -EINVAL; } We already have the equivalent of a CUSTOM memtype because TCMU sets the info->mmap fn, overriding uio's default handling choices in favor of its own. HTH -- Regards -- Andy ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] uio: add UIO_MEM_CUSTOM support 2017-02-16 5:01 ` Andy Grover @ 2017-02-16 5:33 ` Xiubo Li 2017-02-16 6:49 ` Xiubo Li 1 sibling, 0 replies; 5+ messages in thread From: Xiubo Li @ 2017-02-16 5:33 UTC (permalink / raw) To: Andy Grover, Greg KH; +Cc: mchristi, namei.unix, linux-kernel >> For example, the TCMU will use the map area as ISCSI commands & data ring >> buffer(uio0 --> map0). Currently the TCMU will using the fixed small >> size map >> area as the ring buffer, but this will be the bottleneck for high iops. >> >> Without knowing how large it is enough, so the new scheme will use the >> fixed >> small ring buffer area(about 64M ~ 128M) + dynamically "growing" ring >> buffer >> area(about 1.5G). > The following code is in uio_mmap() in uio.c: > > if (idev->info->mmap) { > ret = idev->info->mmap(idev->info, vma); > return ret; Yes, just missed this return. > } > > switch (idev->info->mem[mi].memtype) { > case UIO_MEM_PHYS: > return uio_mmap_physical(vma); > case UIO_MEM_LOGICAL: > case UIO_MEM_VIRTUAL: > return uio_mmap_logical(vma); > default: > return -EINVAL; > } > > We already have the equivalent of a CUSTOM memtype because TCMU sets the > info->mmap fn, overriding uio's default handling choices in favor of its > own. > > HTH -- Regards -- Andy > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] uio: add UIO_MEM_CUSTOM support 2017-02-16 5:01 ` Andy Grover 2017-02-16 5:33 ` Xiubo Li @ 2017-02-16 6:49 ` Xiubo Li 1 sibling, 0 replies; 5+ messages in thread From: Xiubo Li @ 2017-02-16 6:49 UTC (permalink / raw) To: Andy Grover, Greg KH; +Cc: mchristi, namei.unix, linux-kernel >> buffer(uio0 --> map0). Currently the TCMU will using the fixed small >> size map >> area as the ring buffer, but this will be the bottleneck for high iops. >> >> Without knowing how large it is enough, so the new scheme will use the >> fixed >> small ring buffer area(about 64M ~ 128M) + dynamically "growing" ring >> buffer >> area(about 1.5G). > The following code is in uio_mmap() in uio.c: > > if (idev->info->mmap) { > ret = idev->info->mmap(idev->info, vma); > return ret; > } > > switch (idev->info->mem[mi].memtype) { > case UIO_MEM_PHYS: > return uio_mmap_physical(vma); > case UIO_MEM_LOGICAL: > case UIO_MEM_VIRTUAL: > return uio_mmap_logical(vma); > default: > return -EINVAL; > } > > We already have the equivalent of a CUSTOM memtype because TCMU sets the > info->mmap fn, overriding uio's default handling choices in favor of its > own. For the driver like TCMU, the UIO_MEM_NONE could be used with implementing its own ->mmap() magic, instead of adding new UIO_MEM_CUSTOM. But will the semantic be clearer by using _CUSTOM instead of _NONE ? Thanks, BRs Xiubo > HTH -- Regards -- Andy > ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2017-02-16 6:49 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <1487133786-25545-1-git-send-email-lixiubo@cmss.chinamobile.com> 2017-02-15 17:19 ` [PATCH] uio: add UIO_MEM_CUSTOM support Greg KH 2017-02-16 1:34 ` Xiubo Li 2017-02-16 5:01 ` Andy Grover 2017-02-16 5:33 ` Xiubo Li 2017-02-16 6:49 ` Xiubo Li
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.