> Basically, what I want to understand is why does this change make sense?
>
> @@ -1139,6 +1139,10 @@ struct ib_device {
>struct ib_grh *in_grh,
>struct ib_mad *in_mad,
>
>In this case it will not be just mapping remote addresses but creating
>the required AH information which is unique to each device.
I understand that the AH is per device. What I don't get is why we would want
each device to perform the mapping. We don't expect the device to map GIDs to
LIDs wh
> Right, it's already applied.
Doesn't seem to be all there... eg there is nothing for ethernet headers.
--
Roland Dreier || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
___
ewg mailing list
> One reason is that get_src_path_mask() may access ah_lock.
I don't see that:
static u8 get_src_path_mask(struct ib_device *device, u8 port_num)
{
struct ib_sa_device *sa_dev;
struct ib_sa_port *port;
unsigned long flags;
u8 src_path_mask;
sa_dev = ib_
On Thu, May 13, 2010 at 08:55:13AM -0700, Sean Hefty wrote:
> >
> >Interesting idea. Not sure what is better here: a seperate ABI
> >call or some additional 'u8 ctx[32]' field in struct
> >ib_uverbs_create_ah_resp that will be interpreted by the hw-specific
> >user-space driver.
>
> I don't unders
On Thu, May 13, 2010 at 08:48:06AM -0700, Roland Dreier wrote:
>
> Right, I'm not saying it shouldn't be in multicast.c. I'm just
> wondering why you don't have the same thing for sa_query.c.
>
One reason is that get_src_path_mask() may access ah_lock.
___
>Address mapping policies depend on the address type. This patch only
>defines a policy for mapping link-local addresses, and we should
>indeed take care not to change it (if possible).
>Later on, we can add more policies for other address types (e.g.,
>normal IPv6 addresses, mapped IPv4 addresses,
> > Also I'm wondering why you did the "count" stuff to ignore IBoE-only
> > devices in multicast.c but not sa_query.c?
> It seems to me the right place to put this logic as the mutlicast code
> registers as an IB client and the add_one implemntation is
> multicast.c.
Right, I'm not saying i
Also keep in mind that mlx4_en patches typically go through Davem and
netdev, not my tree.
--
Roland Dreier || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
___
ewg mailing list
ewg@lists.openf
On 05/12/2010 01:25 AM, sebastien dugue wrote:
>Hi Justin,
>
>I've been trying to do just that for the past few days.
>
>Right now I managed to have the client working over IB, but it's a gross
> hack
> which will need to be cleaned up.
>
>Tomorrow I'll check with the server part a
On Wed, May 12, 2010 at 01:28:31PM -0700, Roland Dreier wrote:
> > Add ib_uverbs_get_eth_l2_addr() to allow ibv_create_ah() to resolve > dgid> to for any gid type. Although user-space might bypass
> this
> > call for link-local gids, it is better not to replicate the kernel
> resolution
>
On Wed, May 12, 2010 at 01:14:33PM -0700, Roland Dreier wrote:
> > Multicast GIDs are always mapped to multicast MACs
> > as is done in IPv6. Some helper functions are added to ib_addr.h. IPv4
> > multicast is enabled by translating IPv4 multicast addresses to IPv6
> multicast
> > as describe
On Thu, 2010-05-13 at 15:34 +0300, Yevgeny Petrilin wrote:
> Can you please give more details?
> What is the setup? What do you mean by "doesn't work"?
>
>
> Yevgeny Petrilin
> Mellanox Technologies
> Phone: +972-4-9097200 (ext. 7677)
> mailto: yevge...@mellanox.co.il
>
>
> -Original Messa
I installed today OFED-1.5.2-beta1 on the host with ConnectX dual port
card and found the fail-over doesn't work.
On Sun, 2010-03-28 at 10:58 +0300, Vladimir Sokolovsky wrote:
> Or Gerlitz wrote:
> > Hi Vlad, Yevgeny
> >
> > Is there a way to get this fix? AFAIK, this bugzilla system isn't
> there
On Wed, May 12, 2010 at 01:32:01PM -0700, Roland Dreier wrote:
> > + u8 mac_0_1[2];
> > + u8 mac_2_5[4];
>
> This looks a bit odd. Any reason why you don't just have "u8 mac[6];"
> in this structure?
We can get rid of this crap. I think the origin of this is a
limit
On Wed, May 12, 2010 at 01:30:22PM -0700, Roland Dreier wrote:
> > +void *mlx4_get_prot_dev(struct mlx4_dev *dev, enum mlx4_prot proto, int
> port)
> > +{
> > + return mlx4_find_get_prot_dev(dev, proto, port);
> > +}
> > +EXPORT_SYMBOL(mlx4_get_prot_dev);
>
> Not sure I understand why you h
This email was generated automatically, please do not reply
git_url: git://git.openfabrics.org/ofed_1_5/linux-2.6.git
git_branch: ofed_kernel_1_5
Common build parameters:
Passed:
Passed on i686 with linux-2.6.18
Passed on i686 with linux-2.6.19
Passed on i686 with linux-2.6.21.1
Passed on i686
Yevgeny Petrilin wrote:
> Sure, I am preparing the patches
cool.
Is there anything else in that or close importance level mlx4_en wise which is
in ofed and from some reason wasn't push upstream? e.g I see a patch subject
(0119) saying "Fix a crash with prioritiesed vlan packets" this sounds ba
Or Gerlitz wrote:
> Vladimir Sokolovsky wrote:
>> It was fixed in the OFED-1.5.1-rc4, by the following commit: Author: Yevgeny
>> Petrilin Date: Wed Mar 10 18:46:55 2010 +0200
>> mlx4_en: reconfigure mac address
> Hi Yevgeny, I don't see this commit in Linus tree, does this means that the
> up
On Wed, May 12, 2010 at 01:06:36PM -0700, Roland Dreier wrote:
> > 2. Fix wrong implementation of ib_ud_header_init(). A different patch was
> sent
> >to Roland.
>
> This patch no longer applies, I guess because you already sent me this
> fix (which is now upstream since 2.6.34-rc1).
Right
On Wed, May 12, 2010 at 01:05:06PM -0700, Roland Dreier wrote:
> > +static void iboe_mcast_work_handler(struct work_struct *work)
> > +{
> > + struct iboe_mcast_work *mw = container_of(work, struct iboe_mcast_work,
> work);
> > + struct cma_multicast *mc = mw->mc;
> > + struct ib_sa_multic
On Wed, May 12, 2010 at 01:03:42PM -0700, Roland Dreier wrote:
> > int ib_init_ah_from_path(struct ib_device *device, u8 port_num,
> > - struct ib_sa_path_rec *rec, struct ib_ah_attr *ah_attr)
> > + struct ib_sa_path_rec *rec, struct ib_ah_attr *ah_attr,
> >
22 matches
Mail list logo
