All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sage Weil <sage@inktank.com>
To: Ilya Dryomov <ilya.dryomov@inktank.com>
Cc: Alex Elder <elder@ieee.org>,
	Ceph Development <ceph-devel@vger.kernel.org>
Subject: Re: [PATCH 2/6] libceph: add support for CEPH_OSD_OP_SETALLOCHINT osd op
Date: Tue, 25 Feb 2014 09:12:04 -0800 (PST)	[thread overview]
Message-ID: <alpine.DEB.2.00.1402250911020.5145@cobra.newdream.net> (raw)
In-Reply-To: <CALFYKtBkQWkiHnA28xOs-NjBH-5F9ohZ8mR-C+kOkAc=SrA7uA@mail.gmail.com>

On Tue, 25 Feb 2014, Ilya Dryomov wrote:
> >> +                     u64 expected_write_size;
> >
> > Probably the same thing here, a byte might be enough
> > to encode this by using log2(expected_write_size).
> >
> >> +                     __u8 expected_size_probability;
> 
> I think in the interest of genericity expected_object_size should be an
> arbitrary, not limited to a power-of-2 value.  Now, given the current
> 90M object size limit 64 bits might seem a lot, but extent offset and
> length are 64 bit values and to be future-proof I followed that here.
> 
> expected_size_probability is currently unused.  It was supposed to be
> a 0-100 value, indicating whether we expect the object to be smaller
> than expected_object_size or not and how strong that expectation is.
> 
> I'm not sure if you've seen it, but this (both userspace and kernel
> sides) were implemented according to the design laid out by Sage in the
> "rados io hints" thread on ceph-devel about a month ago.  There wasn't
> any discussion that I'm aware of in the interim, that is until the
> recent "wip-hint" thread, which was triggered by my PR.
> 
> >
> > I'm not sure why these single-byte values use __u8 while the
> > multi-byte values use (e.g.) u32.  The leading underscores
> > are supposed to be used for values exposed to user space (or
> > something like that).  Anyway, not a problem with your change,
> > but something maybe you could check into.
> 
> I'm not sure either.  I vaguely assumed it's related to the fact that
> single-byte ceph_osd_req_op fields are directly assigned to the
> corresponding ceph_osd_op fields which are exported to userspace,
> whereas the multi-byte values go through the endianness conversion
> macros, which change the type to __le*.

Oh, good catch.  Yeah, these need to be __le64 so that on the kernel side 
sparse knows what is going on and so on the userspace side the magic __le* 
classes do the endian conversion.

sage

  parent reply	other threads:[~2014-02-25 17:12 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-21 18:55 [PATCH 0/6] libceph: CEPH_OSD_OP_SETALLOCHINT osd op Ilya Dryomov
2014-02-21 18:55 ` [PATCH 1/6] libceph: encode CEPH_OSD_OP_FLAG_* op flags Ilya Dryomov
2014-02-24 14:58   ` Alex Elder
2014-02-21 18:55 ` [PATCH 2/6] libceph: add support for CEPH_OSD_OP_SETALLOCHINT osd op Ilya Dryomov
2014-02-23 16:03   ` Sage Weil
2014-02-24 14:59   ` Alex Elder
2014-02-25 12:52     ` Ilya Dryomov
2014-02-25 13:05       ` Alex Elder
2014-02-25 13:38         ` Ilya Dryomov
2014-02-25 17:12           ` Sage Weil
2014-02-25 17:12       ` Sage Weil [this message]
2014-02-21 18:55 ` [PATCH 3/6] libceph: bump CEPH_OSD_MAX_OP to 3 Ilya Dryomov
2014-02-24 14:59   ` Alex Elder
2014-02-21 18:55 ` [PATCH 4/6] rbd: do not hard-code CEPH_OSD_MAX_OP in rbd_osd_req_callback() Ilya Dryomov
2014-02-24 14:59   ` Alex Elder
2014-02-25 12:53     ` Ilya Dryomov
2014-02-21 18:55 ` [PATCH 5/6] rbd: num_ops parameter for rbd_osd_req_create() Ilya Dryomov
2014-02-24 14:59   ` Alex Elder
2014-02-21 18:55 ` [PATCH 6/6] rbd: prefix rbd writes with CEPH_OSD_OP_SETALLOCHINT osd op Ilya Dryomov
2014-02-24 14:59   ` Alex Elder
2014-02-25 12:58     ` Ilya Dryomov
2014-02-25 13:19       ` Alex Elder
2014-02-23 16:14 ` [PATCH 0/6] libceph: " Sage Weil
2014-02-23 16:15   ` Alex Elder
2014-02-24 14:58 ` Alex Elder
2014-02-25 12:50   ` Ilya Dryomov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.00.1402250911020.5145@cobra.newdream.net \
    --to=sage@inktank.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=elder@ieee.org \
    --cc=ilya.dryomov@inktank.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.