>Are Jason's patches a superset of David's patches? or they need to be
>applied and only then David's work can be re-reviewed/merged, etc?
I believe that Jason's patches are a superset of David's.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to
Sean Hefty wrote:
I'll compare my final patches against the ones submitted by David to see if
anything got missed
Are Jason's patches a superset of David's patches? or they need to be
applied and only then David's work can be re-reviewed/merged, etc?
Or.
--
To unsubscribe from this list: s
On Tue, 2009-11-10 at 13:12 -0800, Sean Hefty wrote:
> >How can we make progress? What are your thoughts?
>
> Help with testing would be great.
Thanks Sean,
I would be glad to do some testing when patches are ready!
>
> - Sean
>
--
To unsubscribe from this list: send the line "unsubscribe
On Tue, Nov 10, 2009 at 01:12:17PM -0800, Sean Hefty wrote:
> >How can we make progress? What are your thoughts?
>
> I'm actually working on this today. I've taken Jason's patch as a
> starting point, and I'm breaking it into separate patches for
> merging and testing. I hope to post the patches
>How can we make progress? What are your thoughts?
I'm actually working on this today. I've taken Jason's patch as a starting
point, and I'm breaking it into separate patches for merging and testing. I
hope to post the patches within the next couple of days. I'll compare my final
patches agains
Jason Gunthorpe wrote:
> On Thu, Oct 29, 2009 at 12:56:01PM -0700, David J. Wilder wrote:
>> On Tue, 2009-10-27 at 23:42 -0600, Jason Gunthorpe wrote:
>>
>>> I left the network namespace stuff alone and kept with the init_net
>>> situation..
>> Another possible solution ;)
>>
>> if (rt->idev->dev-
Jason Gunthorpe wrote:
On Wed, Oct 28, 2009 at 10:05:19AM -0700, Sean Hefty wrote:
A UD endpoint can communicate using multicast and to other UD endpoints. A
user could resolve a UD endpoint before joining a multicast group.
So the IP world analog would be:
fd = socket(AF_INET,SOCK_DGRAM);
c
On Thu, Oct 29, 2009 at 12:56:01PM -0700, David J. Wilder wrote:
>
> On Tue, 2009-10-27 at 23:42 -0600, Jason Gunthorpe wrote:
>
> >
> > I left the network namespace stuff alone and kept with the init_net
> > situation..
>
> Another possible solution ;)
>
> if (rt->idev->dev->flags & IFF_LOOP
On Tue, 2009-10-27 at 23:42 -0600, Jason Gunthorpe wrote:
>
> I left the network namespace stuff alone and kept with the init_net
> situation..
Another possible solution ;)
if (rt->idev->dev->flags & IFF_LOOPBACK){
>
> -static int addr_resolve_remote(struct sockaddr *src_in,
> -
On Wed, Oct 28, 2009 at 10:58:58AM -0700, Sean Hefty wrote:
> >I guess I was hoping you'd be able to do the private data in userspace
> >and avoid those kind of special cases..
>
> The private data would still be done in user space. This allows
> apps that make use of ADDR_CHANGE events to conti
>Hum.. Not sure how that would work? src = AF_INET, dst = AF_IB?
yes - conceptually, these both map to PF_IB, which I think is really the
limiting factor
I'm guessing that you could make the reverse work as well, but it requires more
work and probably wouldn't be used by apps anyway.
>I guess I
On Wed, Oct 28, 2009 at 10:05:19AM -0700, Sean Hefty wrote:
> >Can you explain how rdma_resolve_addr is used in conjunction with
> >multicast? I do not understand what the dest would be. Is it just a man
> >page typo?
>
> A UD endpoint can communicate using multicast and to other UD
> endpoints.
>Can you explain how rdma_resolve_addr is used in conjunction with
>multicast? I do not understand what the dest would be. Is it just a man
>page typo?
A UD endpoint can communicate using multicast and to other UD endpoints. A user
could resolve a UD endpoint before joining a multicast group.
-
On Wed, Oct 28, 2009 at 01:08:33AM -0700, Sean Hefty wrote:
> >Here is how I think this should all go. I can't steal some machines to
> >test it right now (prolly can't till after SC|09), but David/Sean maybe
> >you can have a look at it?
>
> I will try to test it some this week.
Thanks, probably
On Wed, Oct 28, 2009 at 04:49:28PM +0200, Or Gerlitz wrote:
> Jason Gunthorpe wrote:
> > **COMPILE TESTED ONLY**
>
> any reason why other people have to test for you?
Just a preliminary proposal - other people can do whatever they
want. Look at the list of things it fixes and decide your self if
Jason Gunthorpe wrote:
> **COMPILE TESTED ONLY**
any reason why other people have to test for you?
> Convert the address resolution process for outgoing connections
> to be very similar to the way the TCP stack does the same operations.
> This fixes many corner case bugs that can crop up.
rdma_j
>Here is how I think this should all go. I can't steal some machines to
>test it right now (prolly can't till after SC|09), but David/Sean maybe
>you can have a look at it?
I will try to test it some this week.
>AH, there is still another oopsie I just noticed, rdma_resolve_addr
>does not check t
**COMPILE TESTED ONLY**
Convert the address resolution process for outgoing connections
to be very similar to the way the TCP stack does the same operations.
This fixes many corner case bugs that can crop up.
- Process link local scope IPv6 addreses and use sin6_scope_id
to choose the binding d
18 matches
Mail list logo
