On Mon, Aug 05, 2013 at 03:35:22PM -0700, Roland Dreier wrote:
> On Mon, Aug 5, 2013 at 3:22 PM, Jason Gunthorpe
> wrote:
> > Okay, but if you want to narrow things to just be Jeff's application
> > like that, then do we even need this to be part of verbs?
> >
> > IP path MTU should be discovered
On Mon, Aug 5, 2013 at 3:22 PM, Jason Gunthorpe
wrote:
> Okay, but if you want to narrow things to just be Jeff's application
> like that, then do we even need this to be part of verbs?
>
> IP path MTU should be discovered by a netlink routing query to lookup
> the target IP(s), the device maximum
On Mon, Aug 05, 2013 at 01:06:36PM -0700, Roland Dreier wrote:
> On Mon, Aug 5, 2013 at 12:02 PM, Jason Gunthorpe
> wrote:
> >> Wouldn't the following be a better path forward:
> >>
> >> - Add a new API (ibv_get_max_datagram_size() or some such) that
> >> returns the real value as an int, based o
On Mon, Aug 5, 2013 at 12:02 PM, Jason Gunthorpe
wrote:
>> Wouldn't the following be a better path forward:
>>
>> - Add a new API (ibv_get_max_datagram_size() or some such) that
>> returns the real value as an int, based on the true MTU
>> - Have old query verbs continue to return only old MTU v
On Mon, Aug 05, 2013 at 11:48:20AM -0700, Roland Dreier wrote:
> On Wed, Jul 17, 2013 at 10:57 AM, Doug Ledford wrote:
> >>> - doing it this way preserves ABI, so existing binaries are safe
>
> >> I still don't get this. Wouldn't an existing binary be pretty
> >> surprised to get a value wildly
On Wed, Jul 17, 2013 at 10:57 AM, Doug Ledford wrote:
>>> - doing it this way preserves ABI, so existing binaries are safe
>> I still don't get this. Wouldn't an existing binary be pretty
>> surprised to get a value wildly out of range of the enum?
> Yes, but there's no way around that without
On Jul 30, 2013, at 2:31 PM, Christoph Lameter wrote:
> On Tue, 30 Jul 2013, Jeff Squyres (jsquyres) wrote:
>
>> On Jul 30, 2013, at 12:44 PM, Christoph Lameter wrote:
>>
>>> What in the world does that mean? I am an oldtimer I guess. Seems that
>>> this is something that can be done in the ne
On 07/30/2013 02:45 PM, Atchley, Scott wrote:
> http://en.wikipedia.org/wiki/Internet_forum#Thread
>
> "When a member posts in a thread it will jump to the top since it is
> the latest updated thread. Similarly, other threads will jump in
> front of it when they receive posts. When a member posts
On Tue, 30 Jul 2013, Jeff Squyres (jsquyres) wrote:
> On Jul 30, 2013, at 12:44 PM, Christoph Lameter wrote:
>
> > What in the world does that mean? I am an oldtimer I guess. Seems that
> > this is something that can be done in the newfangled forum? How does this
> > affect mailing lists?
>
>
> I
On Jul 30, 2013, at 12:44 PM, Christoph Lameter wrote:
> What in the world does that mean? I am an oldtimer I guess. Seems that
> this is something that can be done in the newfangled forum? How does this
> affect mailing lists?
I'm not sure what you're asking me; please see the prior posts on t
On Mon, 15 Jul 2013, Jeff Squyres (jsquyres) wrote:
> Bump.
What in the world does that mean? I am an oldtimer I guess. Seems that
this is something that can be done in the newfangled forum? How does this
affect mailing lists?
--
To unsubscribe from this list: send the line "unsubscribe linux-rd
On Jul 23, 2013, at 9:26 AM, Jeff Squyres (jsquyres) wrote:
>> .. and UD is the least abstracted transport, so existing apps won't
>> support Jeff's new NIC anyhow, MTU is the least of their problems.
>>
>> Existing apps with existing transports see the same old values.
Bump.
--
Jeff Squyres
On Jul 18, 2013, at 12:50 PM, Jason Gunthorpe
wrote:
>> We need it for UD for our upcoming device, however, because the MTU
>> is the only way to get the max message size.
>
> .. and UD is the least abstracted transport, so existing apps won't
> support Jeff's new NIC anyhow, MTU is the least o
On Thu, Jul 18, 2013 at 02:32:05AM +, Jeff Squyres (jsquyres) wrote:
> On Jul 17, 2013, at 5:44 PM, Steve Wise wrote:
>
> > The iwarp drivers just report the nearest mtu enum. Apps don't need it for
> > iwarp like they do for ib.
> For RC, it doesn't matter much. So the fact that RoCE and
On Jul 17, 2013, at 5:44 PM, Steve Wise wrote:
> The iwarp drivers just report the nearest mtu enum. Apps don't need it for
> iwarp like they do for ib.
For RC, it doesn't matter much. So the fact that RoCE and iWARP lie about
their MTU isn't a huge deal. It's wrong, but it doesn't matter
On 7/17/2013 4:41 PM, Hefty, Sean wrote:
I hadn't looked at the kernel side yet; I was waiting for the userspace side to
sort itself out first.
I think it makes sense to start with how user space can get the data. Without
eating up reserved fields, we're starting with 8 bit values.
Hmm. 16
> I hadn't looked at the kernel side yet; I was waiting for the userspace side
> to
> sort itself out first.
I think it makes sense to start with how user space can get the data. Without
eating up reserved fields, we're starting with 8 bit values.
> Hmm. 16 bits is probably enough for the MTU
On Jul 17, 2013, at 12:06 AM, "Hefty, Sean" wrote:
> I don't remember. Is it known how the mtu is communicated with the kernel?
I hadn't looked at the kernel side yet; I was waiting for the userspace side to
sort itself out first.
> Looking at kern-abi.h, the mtu fields are:
>
> struct ibv
On 07/16/2013 08:16 PM, Roland Dreier wrote:
> On Tue, Jul 16, 2013 at 10:11 AM, Jeff Squyres (jsquyres)
> wrote:
>> - doing it this way preserves ABI, so existing binaries are safe
>
> I still don't get this. Wouldn't an existing binary be pretty
> surprised to get a value wildly out of range o
> > A source change is completely unvaoidable. Supporting the new MTU
> > values requires updated source.
>
>
> I don't really care one way or the other; I'll submit whatever patch people
> want. :-)
>
> But FWIW, I tend to believe the Doug/Jason position:
>
> - MTU really needs to be a plain
On Tue, Jul 16, 2013 at 10:11 AM, Jeff Squyres (jsquyres)
wrote:
> - doing it this way preserves ABI, so existing binaries are safe
I still don't get this. Wouldn't an existing binary be pretty
surprised to get a value wildly out of range of the enum?
- R.
--
To unsubscribe from this list: sen
On Jul 16, 2013, at 10:47 AM, Jason Gunthorpe
wrote:
> A source change is completely unvaoidable. Supporting the new MTU
> values requires updated source.
I don't really care one way or the other; I'll submit whatever patch people
want. :-)
But FWIW, I tend to believe the Doug/Jason positio
On Tue, Jul 16, 2013 at 08:04:08AM +, Hefty, Sean wrote:
> > > Jeff's patch doesn't break old binaries, old binaries, running with
> > > normal IB MTUs work fine. The structure layouts all stay the same,
> > > etc.
> >
> >
> > FWIW, I did a simple test to confirm this. I installed a stock gi
> > Jeff's patch doesn't break old binaries, old binaries, running with
> > normal IB MTUs work fine. The structure layouts all stay the same,
> > etc.
>
>
> FWIW, I did a simple test to confirm this. I installed a stock git HEAD
> libibverbs into $HOME/libibverbs-HEAD and a libibverbs with the
Bump.
On Jul 10, 2013, at 8:14 AM, Jeff Squyres (jsquyres) wrote:
> On Jul 8, 2013, at 1:26 PM, Jason Gunthorpe
> wrote:
>
>> Jeff's patch doesn't break old binaries, old binaries, running with
>> normal IB MTUs work fine. The structure layouts all stay the same,
>> etc.
>
>
> FWIW, I did a
On Jul 8, 2013, at 1:26 PM, Jason Gunthorpe
wrote:
> Jeff's patch doesn't break old binaries, old binaries, running with
> normal IB MTUs work fine. The structure layouts all stay the same,
> etc.
FWIW, I did a simple test to confirm this. I installed a stock git HEAD
libibverbs into $HOME/l
On Mon, Jul 08, 2013 at 10:19:33AM -0700, Roland Dreier wrote:
> [resending to reply-all, sorry Jeff]
>
> On Mon, Jul 8, 2013 at 9:26 AM, Jeff Squyres (jsquyres)
> wrote:
> >> So what happens if I have an old application binary, and I run against
> >> a new libibverbs without recompiling?
>
> >>
[resending to reply-all, sorry Jeff]
On Mon, Jul 8, 2013 at 9:26 AM, Jeff Squyres (jsquyres)
wrote:
>> So what happens if I have an old application binary, and I run against
>> a new libibverbs without recompiling?
>> Also it seems that I'm forced to change my source code to be able to
>> compil
On Jul 5, 2013, at 3:11 PM, Roland Dreier wrote:
> So what happens if I have an old application binary, and I run against
> a new libibverbs without recompiling?
>
> Also it seems that I'm forced to change my source code to be able to
> compile against new libibverbs?
I previously sent an ABI-
On Tue, Jul 2, 2013 at 5:31 AM, Jeff Squyres wrote:
> Keep IBV_MTU_* enums values as they are, but pass MTU values around as
> a struct containing a single int.
>
> Per lengthy discusson on the linux-rdma list, this patch introdces a
> source code incompatibility. Although legacy applications can
Bump.
On Jul 2, 2013, at 8:31 AM, Jeff Squyres wrote:
> (Previous patch did not include updates for the man pages)
>
> Keep IBV_MTU_* enums values as they are, but pass MTU values around as
> a struct containing a single int.
>
> Per lengthy discusson on the linux-rdma list, this patch intro
(Previous patch did not include updates for the man pages)
Keep IBV_MTU_* enums values as they are, but pass MTU values around as
a struct containing a single int.
Per lengthy discusson on the linux-rdma list, this patch introdces a
source code incompatibility. Although legacy applications can
On Jun 21, 2013, at 5:20 PM, Jason Gunthorpe
wrote:
> Jeff: If you are still reading -
I am still reading, just didn't have much to contribute until now. :-)
> one concrete suggestion, I think, is
> to ensure compile-time failure when the new-format MTU variable is
> touched. This is trivial
> > I'm ready for a new project. I already had one in mind,
> > but it required some changes to libibverbs that are pretty deep changes.
> > Instead of doing that deep work in libibverbs, I can start here and
> > move on to my next project when this is up and running.
>
> That would be amazing
On Fri, Jun 21, 2013 at 04:57:09PM -0400, Doug Ledford wrote:
> > I disagree, *verbs* needs to expose the HW capabilities, efficiently.
>
> What we need is an efficient RDMA API (of which verbs is a candidate for
> the underlying implementation). It need not expose HW capabilities in
> its base
On 06/21/2013 02:26 PM, Jason Gunthorpe wrote:
> On Fri, Jun 21, 2013 at 01:36:01PM -0400, Doug Ledford wrote:
>
> The new transports have new requirements, and the apps have new
> required behaviors - the API simply can't hide all this in every
> case. The changes before had nothing t
On Fri, Jun 21, 2013 at 01:36:01PM -0400, Doug Ledford wrote:
> >>> The new transports have new requirements, and the apps have new
> >>> required behaviors - the API simply can't hide all this in every
> >>> case. The changes before had nothing to do with MTU, FWIW.
> >>
> >> It demonstrates what
On 06/21/2013 02:36 AM, Jason Gunthorpe wrote:
> On Thu, Jun 20, 2013 at 08:31:07PM -0400, Doug Ledford wrote:
>
>>> The new transports have new requirements, and the apps have new
>>> required behaviors - the API simply can't hide all this in every
>>> case. The changes before had nothing to do w
On Thu, Jun 20, 2013 at 08:31:07PM -0400, Doug Ledford wrote:
> > The new transports have new requirements, and the apps have new
> > required behaviors - the API simply can't hide all this in every
> > case. The changes before had nothing to do with MTU, FWIW.
>
> It demonstrates what I would ca
> I would argue that this is because the libraries are so disjoint (that
> librdmacm needs the deep internal knowledge it needs of libibverbs
> indicates that maybe these two shouldn't be separate from each other for
> example, or that maybe libibverbs should provide a unified connection
> API to t
On 06/20/2013 05:14 PM, Jason Gunthorpe wrote:
> On Thu, Jun 20, 2013 at 04:31:14PM -0400, Doug Ledford wrote:
>>> happened for iwarp, rocee, etc.
>>
>> If it happened once, then I would agree with you above. That it *keeps*
>> happening is the issue. To me, that's a clear indication that instead
On Thu, Jun 20, 2013 at 04:31:14PM -0400, Doug Ledford wrote:
> > happened for iwarp, rocee, etc.
>
> If it happened once, then I would agree with you above. That it *keeps*
> happening is the issue. To me, that's a clear indication that instead
> of fixing the shortcomings of the current API pr
On 06/20/2013 12:53 PM, Jason Gunthorpe wrote:
> On Thu, Jun 20, 2013 at 12:34:04PM -0400, Doug Ledford wrote:
>> On 06/20/2013 10:21 AM, Jeff Squyres wrote:
>>> Keep IBV_MTU_* enums values as they are, but pass MTU values around as
>>> int's. This is an ABI-compatible change; legacy applications
On Thu, Jun 20, 2013 at 12:34:04PM -0400, Doug Ledford wrote:
> On 06/20/2013 10:21 AM, Jeff Squyres wrote:
> > Keep IBV_MTU_* enums values as they are, but pass MTU values around as
> > int's. This is an ABI-compatible change; legacy applications will use
> > the enum values,
>
> I'm not really
On 06/20/2013 12:34 PM, Doug Ledford wrote:
> On 06/20/2013 10:21 AM, Jeff Squyres wrote:
>> Keep IBV_MTU_* enums values as they are, but pass MTU values around as
>> int's. This is an ABI-compatible change; legacy applications will use
>> the enum values,
>
> I'm not really concerned with what t
On 06/20/2013 10:21 AM, Jeff Squyres wrote:
> Keep IBV_MTU_* enums values as they are, but pass MTU values around as
> int's. This is an ABI-compatible change; legacy applications will use
> the enum values,
I'm not really concerned with what the legacy apps use so much as what
they are presented
Keep IBV_MTU_* enums values as they are, but pass MTU values around as
int's. This is an ABI-compatible change; legacy applications will use
the enum values, but newer applications can use an int for values that
do not currently exist in the enum set (e.g., 1500, 9000).
(if people like the idea o
47 matches
Mail list logo
