Roland Dreier wrote: > > I tested it before on the Roland tree ( iboe branch ) and it fails, > > because it writen in the way suitable for OFED. If adapt the patch to > > the Roland tree, then appling Mellanox OFED patches will fail, because > > it changes the same functions in the code. > > Here is one example: > > Look at __mlx4_ib_modify_qp at the Roland tree - there is no RAW_ETY > > support. But in the OFED version of the same function this support is > > present. > > RAW_ETH patch modify this function and looking for RAW_ETY word and > > without this RAW_ETH Mellanox patch will fail. > > Don't take this too personally -- I picked a semi-random email in this > thread to reply to; this is pretty broadly targeted. > > <rant> > > What the hell is the thinking behind introducing IB_QPT_RAW_ETH? You're > inserting an enum value before IB_QPT_RAW_ETY, so any old userspace > passing in IB_QPT_RAW_ETY will silently get different behavior depending > on the kernel version. And you're creating two constands that differ in > a single letter (IB_QPT_RAW_ETY vs. IB_QPT_RAW_ETH). How are you going > to explain that to users? How is anyone ever going to get it right? > For that matter, what exactly does IB_QPT_RAW_ETH mean? > > This all seems to be a symptom of how broken our development process > is. Yes, unfortunately I can't spend as much time reviewing and > applying patches as I might like, and I apologize for that. But if we > have all the RDMA developers piling up shit in their little area and > then sending it on to be merged as soon as it kind of works, without > thinking about design or maintainability and without ever doing any > review, then I'm always going to have an expanding review backlog. > > And then we have OFED compounding problems -- "Oh that's a nice pile of > shit you've built there. We better ship it to users while it's still > steaming." How about if OFED developers take a little time to think > things through? > > </rant> > > In other words, can someone explain the plan for this raw QP stuff to me? > > - R. >
It doesn't even look like this patch and the mlx4 patch were ever posted to linux-rdma. Only to the EWG list. Granted our dev process may not be documented, but I always assumed the general idea was to get changes accepted upstream, then pull into ofed. OFED is just a mechanism to make top-of-tree linux work on distro kernels. There are some exceptions, but this stuff shouldn't be an exception. We should all follow this "upstream first" process IMO. Steve. _______________________________________________ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
