login
Search
Since 2.6.23 still isn't out, and I've managed to reduce my patch
review backlog a bit, it's probably a good idea to give another update
about what I have queued for 2.6.24 already and what I hope to get to
before the merge window opens.Core:
- My user_mad P_Key index support patch. Merged this, although I
still owe Sasha a patch to update libraries to use this.- A fix to the user_mad 32-bit big-endian userspace 64/32 problem
with the method_mask when registering agents. Merged.- Sean's QoS changes. Merged.
- Sean's IB CM MRA interface changes. I merged these -- what the
heck, if it breaks we can back them out.ULPs:
- Pradeep's IPoIB CM support for devices that don't have SRQs. Sean
started reviewing but I didn't see any updated patches.- Moni's IPoIB bonding support. Seems like we found a clean set of
changes, and these will go in via another (Jeff Garzik's?) tree.- Rolf's IPoIB MGID scope changes. No review progress here.
- Eli and Michael's IPoIB stateless offload (checksum offload, LSO,
LRO, etc). Not much review progress here; I'll try to chip away at
the series and see what we can get into 2.6.24.- Or's IPoIB/userspace multicast coexistence stuff. I think we've
converged on this; I'll merge this once a final version of the
patch appears.HW specific:
- I already merged patches to enable MSI-X by default for mthca and
mlx4. I hope there aren't too many systems that get hosed if a
MSI-X interrupt is generated.- Jack and Michael's mlx4 FMR support. Merged. I guess the fix for
running in Xen domU may need to wait for 2.6.25, but I'll see what
I can do.- ehca patch queue. Merged everything I think.
- Steve's mthca router mode support. No one looked at it, seems like
it's at risk of missing the window.- Arthur's mthca doorbell alignment fixes. I still need to check
various approaches; I'll definitely merge something for 2.6.24.- Michael's mlx4 WQE shrinking...
I posted the first draft patch set to the OpenFabrics list on September 18:
[ofa-general] [PATCH 0 of 5] XRC implementation patches (libibverbs, libmlx=
4, core, mlx4) Jack Morgenstein
[ofa-general] [PATCH 1 of 5] libibverbs: XRC implementation Jack Morgenst=
ein
[ofa-general] [PATCH 2 of 5] libmlx4: XRC implementation Jack Morgenstein
[ofa-general] [PATCH 3 of 5] core: XRC implementation for fd =3D -1 when op=
ening an xrc domain Jack Morgenstein
[ofa-general] [PATCH 4 of 5] core: XRC implementation -- add support for wo=
rking with file descriptors Jack Morgenstein
[ofa-general] [PATCH 5 of 5] mlx4: XRC implementation Jack MorgensteinThe above patch set implements XRC for userspace verbs layer and below.
The Kernel-space verbs implementation (1 more patch) is finished,
but as yet untested.=2D Jack
_______________________________________________
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/generalTo unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
> > - XRC. Given the length of the backlog above and the fact that a
> > first draft of this code has not been posted yet, I don't see any
> > way that we could have something this major ready in time.
> >
> I posted the first draft patch set to the OpenFabrics list on September 18:Sorry, I didn't update that text. But my backlog is still too big to
get XRC into 2.6.24.- R.
_______________________________________________
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/generalTo unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
No mention about the iwarp port space issue?
Here is the status of the current proposed patch:
- needs another round of changes based on Sean's feedback
- Arkady raised issues about the pain this puts on admins
- it forces services like nfs-rdma, which already separates the nfs-rdma
server by port number, to needlessly use a separate subnet for the rdma
service.I'm at a loss as to how to proceed.
Any ideas?
Steve.
_______________________________________________
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/generalTo unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
> No mention about the iwarp port space issue?
I don't think we're at a stage where I'm prepared to merge something--
we all agree the latest patch has serious drawbacks, and it commits us
to a suboptimal interface that is userspace-visible.> I'm at a loss as to how to proceed.
Could we try to do some cleanups to the net core to make the alias
stuff less painful? eg is there any sane way to make it possible for
a device that creates 'eth0' to also create an 'iw0' alias without an
assigning an address?- R.
_______________________________________________
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/generalTo unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Well, "alias" interfaces really don't exist. ethX:iw is really just
adding a address record (struct in_ifaddr) to ethX. So in the current
core design, adding an alias without an address is really adding the
alias with address 0.0.0.0. And I think the core net code assumes if an
in_ifaddr struct exists for a device, then its IP address is indeed valid.So I think the changes wouldn't be small to enhance the design to add a
concept of an alias interface.I'll look into this more though.
Steve.
_______________________________________________
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/generalTo unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Roland, I submitted an updated patch incorporating some of Sean's comments within
a day or two. Rest of comments pertained to restructuring the code and adding
some additional module parameters.This would require more discussions since some of these had been already discussed
previously. We had decided upon this code structure after a lot of discussions and
incorporating these would be undoing some of that.We can discuss and revisit the comments after the merge.
Pradeep
_______________________________________________
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/generalTo unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
> Roland, I submitted an updated patch incorporating some of Sean's comments within
> a day or two. Rest of comments pertained to restructuring the code and adding
> some additional module parameters.
>
> This would require more discussions since some of these had been already discussed
> previously. We had decided upon this code structure after a lot of discussions and
> incorporating these would be undoing some of that.Can you give a link to your current final version of the patch?
Sean, what's your opinion of where we stand?
Since module parameters create a userspace-visible interface that we
are stuck with for a long time, we definitely have to get at least
that much right before merging.- R.
_______________________________________________
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/generalTo unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Roland,
This is the link to the last one that I submitted on 09/18.
http://lists.openfabrics.org/pipermail/general/2007-September/040917.html
Pradeep
_______________________________________________
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/generalTo unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Let me look back over the last version that was sent and reply back
later today or tomorrow. Several of my initial comments were on codeI was taking a slightly different view of the design. It would be nice
to agree on whether SRQ should be separated from the QP type before
merging upstream, even if the implementation doesn't immediately support
all available options.- Sean
_______________________________________________
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/generalTo unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
| debian developer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg Kroah-Hartman | [PATCH 001/196] Chinese: Add the known_regression URI to the HOWTO |
| Linus Torvalds | Re: Slow DOWN, please!!! |
| Tony Lindgren | [PATCH 37/90] ARM: OMAP: MPUIO wake updates |
git: | |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 15/37] dccp: Set per-connection CCIDs via socket options |
| Alexey Dobriyan | Re: [GIT]: Networking |
| Dushan Tcholich | Re: ksoftirqd high cpu load on kernels 2.6.24 to 2.6.27-rc1-mm1 |
