> This was added in the past when I wanted to use the pointer to the net
> device to resolve any IPv6 address. Since we only resolve link local
> addresses, why don't we just remove the spinlocks and the check inside
> it?
OK, easy enough.
- R.
--
To unsubscribe from this list: send the line
> I don't get this. For IB, we have 72 without immediate - did you
> forget to add the ICRC? I think we count it with the header...
We don't need ICRC in the header_buf, do we? We're talking about
MLX4_IB_UD_HEADER_SIZE, which is used to hold the packet header we get
from ib_ud_header_pack().
On Thu, Oct 21, 2010 at 02:15:47PM -0700, Roland Dreier wrote:
> > (It probably works in practice because the allocation of sqp structs
> > gets rounded up enough)
>
> And I guess also no one actually ends up sending MADs with immediate
> data, so that saves 4 bytes off the worst case too...
I
On Thu, Oct 21, 2010 at 02:14:11PM -0700, Roland Dreier wrote:
> > enum {
> >/*
> > * Largest possible UD header: send with GRH and immediate data.
> > + * 4 bytes added to accommodate for eth header instead of lrh
> > */
> > - MLX4_IB_UD_HEADER_SIZE = 72,
> > + MLX
On Thu, Oct 21, 2010 at 12:57:31PM -0700, Roland Dreier wrote:
> Also I don't see anywhere that the global functions
>
> > +int eth_to_ib_width(int w)
> > +int eth_to_ib_speed(int s)
>
> are called?
>
Right. Let's remove them.
--
To unsubscribe from this list: send the line "unsubscribe linux
On Thu, Oct 21, 2010 at 12:48:00PM -0700, Roland Dreier wrote:
> int mlx4_ib_resolve_grh(struct mlx4_ib_dev *dev, const struct ib_ah_attr
> *ah_attr,
> u8 *mac, int *is_mcast, u8 port)
> {
> struct mlx4_ib_iboe *iboe = &dev->iboe;
> struct in6_addr in6;
>
>
> (It probably works in practice because the allocation of sqp structs
> gets rounded up enough)
And I guess also no one actually ends up sending MADs with immediate
data, so that saves 4 bytes off the worst case too...
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> enum {
> /*
> * Largest possible UD header: send with GRH and immediate data.
> + * 4 bytes added to accommodate for eth header instead of lrh
> */
> -MLX4_IB_UD_HEADER_SIZE = 72,
> +MLX4_IB_UD_HEADER_SIZE = 76,
I don't understand this chang
Also I don't see anywhere that the global functions
> +int eth_to_ib_width(int w)
> +int eth_to_ib_speed(int s)
are called?
- R.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.k
> > Just curious -- what's up with this change here? Is this connected to
> > IBoE support, or is this an independent fix?
>
> It is required for proper distribution of IBoE multicast packets while
> still not hurting the mlx4_en driver's operation.
OK, I split this into a separate patch fo
Thanks Jason,
That fixed it.
Bob
-Original Message-
From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com]
Sent: Thursday, October 21, 2010 11:48 AM
To: Bob Pearson
Cc: linux-rdma@vger.kernel.org
Subject: Re: libverbs version confusion
On Thu, Oct 21, 2010 at 01:00:55AM -0500,
Does anyone know what the latest perftest.git tree is? Has this been moved
over to the new server?
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Oct 21, 2010 at 01:00:55AM -0500, Bob Pearson wrote:
> I have an application that links to -libverbs (1.5.2) and for some reason
> ibv_open_device goes to the compat 1.0 version not the default one. Other
> apps in the same development tree and the standard ones like ib_send_bw all
> link t
The flushing of work requests for user QPs is implemented entirely in the
user mode library. The only kernel interaction is to mark the user QP
object indicating it is in error when the QP exits RTS. When the user
QP operations are called by the application (eg: post_send, post_recv),
the QP in e
On 10/20/2010 4:12 PM, Hefty, Sean wrote:
I applied this, but am waiting on the other patch until the discussion finishes
up.
Since pthread_cancel() seems to be iffy for user verbs, maybe I'll try
another approach: Since the rping main thread issues an
rdma_disconnect(), we can assume that
On Thu, Oct 21, 2010 at 12:16 PM, Bart Van Assche wrote:
>
> On Wed, Oct 20, 2010 at 11:16 PM, Jason Gunthorpe
> wrote:
> > On Wed, Oct 20, 2010 at 03:56:38PM -0500, Steve Wise wrote:
> >
> >> Hey Jason, do you have a pointer to the list of pthread cancellation
> >> points for Linux?
> >
> > Sure
On Wed, Oct 20, 2010 at 11:16 PM, Jason Gunthorpe
wrote:
> On Wed, Oct 20, 2010 at 03:56:38PM -0500, Steve Wise wrote:
>
>> Hey Jason, do you have a pointer to the list of pthread cancellation
>> points for Linux?
>
> Sure do
>
> http://www.kernel.org/doc/man-pages/online/pages/man7/pthreads.7.htm
On Wed, Oct 20, 2010 at 10:22:56PM -0700, Roland Dreier wrote:
> Just curious -- what's up with this change here? Is this connected to
> IBoE support, or is this an independent fix?
It is required for proper distribution of IBoE multicast packets while
still not hurting the mlx4_en driver's opera
18 matches
Mail list logo
