Re: [ewg] [PATCH v4] IB Core: RAW ETH support

Roland Dreier
2010-06-15T21:14:36Z

> 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.
--
Roland Dreier <rolandd-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org> || For corporate legal information go to: