(unknown),

(unknown),

[John Dykstra]

subscribe

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(unknown),

[ATTENTION]

You are a winner of 750,000.00 GBP in Toyota promo Award.Reply us your
Name...
Address....
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(unknown),

[CBH QINGDAO LIMITED]

Our Company CBH QINGDAO LIMITED,China. We are interested 
in Employing your Service as our Payment Collector in your 
region, you will be entitled to 10% agentship commission 
fee for every payment been recieved by you from our 
creditor.Email: (cbhcompany221-dbdLmdGazhY@public.gmane.org)

Regards,
Bill Yang.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(unknown)

[Jason Gunthorpe]

Bcc: 
Subject: Re: igmp: Staggered igmp report intervals for unsolicited igmp
	reports
Reply-To: 
In-Reply-To: <OF871D4733.876C9DA0-ON882577AB.006AB200-882577AB.006B6101-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>

On Mon, Sep 27, 2010 at 12:32:45PM -0700, David Stevens wrote:
 
> You can, of course, add a querier (or configure it, assuming an
> attached switch supports it) and set the query interval and
> robustness count as appropriate for that network.

Presumably the IPoIB multicast router should already be the querier..
How does this help handling joins to new groups?

> As would be having those networks queue packets for hardware
> addresses they know require a delay before a transmit can
> complete. But that approach can't adversely affect already-working
> solutions for typical networks, or depart unnecessarily from
> established standard protocols.

There is no way to know when a hardware address is 'ready' in a IGMPv2
sense.. The problem with IGMPv2 and any network that doesn't flood
multicast to all nodes is that there is no way to know when all IGMPv2
listeners are listening on the group you just created.

For IGMPv2 there is a special hack in the IPoIB routers that cause
them to automatically join the IP multicast groups as they are created
so they can get the per-group IGMP messages, and this process takes
time and is completely opaque to the end nodes.

IB could emulate something like ethernet flooding by sending packets
to the permanent 'broadcast' (all-IP-endpoints) multicast group - but
it has no way to know when that is necessary and when it is not.

Sending IGMPv2 packets to the group address that is being managed
(rather than an IGMP specific group like in v3) is a design choice
that probably only works well on ethernet :(

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re:

[David Stevens]

Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> wrote on 09/27/2010 
01:05:00 PM:

> On Mon, Sep 27, 2010 at 12:32:45PM -0700, David Stevens wrote:
> 
> > You can, of course, add a querier (or configure it, assuming an
> > attached switch supports it) and set the query interval and
> > robustness count as appropriate for that network.
> 
> Presumably the IPoIB multicast router should already be the querier..
> How does this help handling joins to new groups?

        Because a querier can set the robustness value and
query interval to anything you want. In the original report,
he's not running a querier. The fact that it's a new group
doesn't matter -- these are per-interface.

                                                        +-DLS

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re:

[Christoph Lameter]

On Mon, 27 Sep 2010, David Stevens wrote:

>         Because a querier can set the robustness value and
> query interval to anything you want. In the original report,
> he's not running a querier. The fact that it's a new group
> doesn't matter -- these are per-interface.

The per interface settings are used to force an IGMP version overriding
any information by the queriers. You would not want to enable that because
it disables support for other IGMP versions. Without the override
different version of IGMP can be handled per MC group.

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re:

[Bob Arendt]

On 09/27/10 13:23, Christoph Lameter wrote:
> On Mon, 27 Sep 2010, David Stevens wrote:
>
>>          Because a querier can set the robustness value and
>> query interval to anything you want. In the original report,
>> he's not running a querier. The fact that it's a new group
>> doesn't matter -- these are per-interface.
>
> The per interface settings are used to force an IGMP version overriding
> any information by the queriers. You would not want to enable that because
> it disables support for other IGMP versions. Without the override
> different version of IGMP can be handled per MC group.
>
If a network vlan has IGMPv3 capability, then it should be able
to support both v2 and v3 Joins (clients).  But if the vlan is
IGMPv2 only, then an initial Join from a Linux client might go out
as v3 (if it hasn't seen a query yet) and be ignored.  I believe
this is the case that force_igmp_version really addresses.

And it turns out that  force_igmp_version=2 doesn't fully work.
If the host sees a IGMPv3 query, it still responds with a v3 Join
despite the flag.  Bug report and candidate patch here:
https://bugzilla.kernel.org/show_bug.cgi?id=18212
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re:

[David Stevens]

Christoph Lameter <cl-vYTEC60ixJUAvxtiuMwx3w@public.gmane.org> wrote on 09/27/2010 01:23:00 PM:

> From: Christoph Lameter <cl-vYTEC60ixJUAvxtiuMwx3w@public.gmane.org>
> To: David Stevens/Beaverton/IBM@IBMUS
> Cc: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>, linux-
> rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, netdev-
> owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Bob Arendt <rda-x0S3BwdUo6DQT0dZR+AlfA@public.gmane.org>
> Date: 09/27/2010 01:23 PM
> Subject: Re:
> 
> On Mon, 27 Sep 2010, David Stevens wrote:
> 
> >         Because a querier can set the robustness value and
> > query interval to anything you want. In the original report,
> > he's not running a querier. The fact that it's a new group
> > doesn't matter -- these are per-interface.
> 
> The per interface settings are used to force an IGMP version overriding
> any information by the queriers.

        No. I'm not talking about the force_igmp_tunable here, I'm talking
about the per-interface robustness and interval settings which come from
the querier (whatever version you are using).

> You would not want to enable that because
> it disables support for other IGMP versions. Without the override
> different version of IGMP can be handled per MC group.

        No. IGMPv3 includes backward compatibility for both IGMPv2 and
IGMPv1. If queries for an earlier version are present, that is the
IGMP version all use, and the features of the later version are not
available to anyone.

                                                                +-DLS


--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re:

[David Stevens]

Bob Arendt <rda@rincon.com> wrote on 09/27/2010 01:54:36 PM:
 
> On 09/27/10 13:23, Christoph Lameter wrote:
> > On Mon, 27 Sep 2010, David Stevens wrote:
> >
> >>          Because a querier can set the robustness value and
> >> query interval to anything you want. In the original report,
> >> he's not running a querier. The fact that it's a new group
> >> doesn't matter -- these are per-interface.
> >
> > The per interface settings are used to force an IGMP version 
overriding
> > any information by the queriers. You would not want to enable that 
because
> > it disables support for other IGMP versions. Without the override
> > different version of IGMP can be handled per MC group.
> >
> If a network vlan has IGMPv3 capability, then it should be able
> to support both v2 and v3 Joins (clients).  But if the vlan is
> IGMPv2 only, then an initial Join from a Linux client might go out
> as v3 (if it hasn't seen a query yet) and be ignored.  I believe
> this is the case that force_igmp_version really addresses.

        Not really. It's for the case where there is no querier at all,
but a snooping switch that only supports IGMPv2. After any query has
put an interface in IGMPv2 mode (or IGMPv1), the initial report for
all joins will use the earlier protocol. It isn't per-group, it's
per interface, and you cannot mix versions of IGMP on the same network.

> 
> And it turns out that  force_igmp_version=2 doesn't fully work.
> If the host sees a IGMPv3 query, it still responds with a v3 Join
> despite the flag.  Bug report and candidate patch here:
> https://bugzilla.kernel.org/show_bug.cgi?id=18212

        This is a special case. The "correct" alternative is to drop
the query and not send any report at all. Sending an answer in the
originating protocol doesn't hurt anything here, because MC routers
are required to use the earlier version too; there should be no such
thing as an "IGMPv3-only querier" as in that report. IGMPv3 compliance
*requires* falling back to IGMPv2 if there is a v2 query by another
router. 
        By answering instead of dropping, it allows fuller filter
information from a manual query to be returned even if the network
is using v2 MC routers, but dropping and ignoring the query as
required by RFC does not fix the bug & patch submitter's problem.
Which is why I also NACKed that patch.

                                                        +-DLS

Re: IGMP v3 reponse

[Bob Arendt]

On 09/27/10 15:01, David Stevens wrote:
> Bob Arendt<rda@rincon.com>  wrote on 09/27/2010 01:54:36 PM:
>> And it turns out that  force_igmp_version=2 doesn't fully work.
>> If the host sees a IGMPv3 query, it still responds with a v3 Join
>> despite the flag.  Bug report and candidate patch here:
>> https://bugzilla.kernel.org/show_bug.cgi?id=18212
>
>          This is a special case. The "correct" alternative is to drop
> the query and not send any report at all. Sending an answer in the
> originating protocol doesn't hurt anything here, because MC routers
> are required to use the earlier version too; there should be no such
> thing as an "IGMPv3-only querier" as in that report. IGMPv3 compliance
> *requires* falling back to IGMPv2 if there is a v2 query by another
> router.
>          By answering instead of dropping, it allows fuller filter
> information from a manual query to be returned even if the network
> is using v2 MC routers, but dropping and ignoring the query as
> required by RFC does not fix the bug&  patch submitter's problem.
> Which is why I also NACKed that patch.
>
>                                                          +-DLS
>
>
Per rfc 2236, the v2 client *can't* drop the IGMPv3 query.  From para 2.5:
   2.5.  Other fields
    Note that IGMP messages may be longer than 8 octets, especially
    future backwards-compatible versions of IGMP.  As long as the Type is
    one that is recognized, an IGMPv2 implementation MUST ignore anything
    past the first 8 octets while processing the packet.  However, the
    IGMP checksum is always computed over the whole IP payload, not just
    over the first 8 octets.

The IGMPv3 query *is* a valid v2 query with extra crap at the end (it's
backward compatible).  Per rfc 2236 p2.5, the v3 query has to be regarded
as a valid v2 query if you're correctly implementing IGMPv2.  Some switch
vendors (Cisco for one) only generate v3 queries when operating as an
IGMP snooping switch, since a proper v2 client will respond with IGMPv2
packets and it handles this properly.  However, we're seeing some switches
get confused when a client initial joins with v2, then responds to a query
with v3.  It ends up creating 2 entries, and only one is cleared by the
leave message.  This is also an issue when the primary (querier) switch
only generates v3 queries, and some intermediate switches only support v2.
We set all the Linux clients to v2 .. but they respond the v2 query with
v3 protocols, which could be missed by the intermediate switch.

I believe the intent of the bug 18212 patch is correct.

-Bob Arendt

Re: IGMP v3 reponse

[David Stevens]

Bob Arendt <rda-x0S3BwdUo6DQT0dZR+AlfA@public.gmane.org> wrote on 09/27/2010 04:51:15 PM:

> Per rfc 2236, the v2 client *can't* drop the IGMPv3 query.  From para 
2.5:
>    2.5.  Other fields
>     Note that IGMP messages may be longer than 8 octets, especially
>     future backwards-compatible versions of IGMP.  As long as the Type 
is
>     one that is recognized, an IGMPv2 implementation MUST ignore 
anything
>     past the first 8 octets while processing the packet.  However, the
>     IGMP checksum is always computed over the whole IP payload, not just
>     over the first 8 octets.
> 
> The IGMPv3 query *is* a valid v2 query with extra crap at the end (it's
> backward compatible).  Per rfc 2236 p2.5, the v3 query has to be 
regarded
> as a valid v2 query if you're correctly implementing IGMPv2.  Some 
switch
> vendors (Cisco for one) only generate v3 queries when operating as an
> IGMP snooping switch, since a proper v2 client will respond with IGMPv2
> packets and it handles this properly.  However, we're seeing some 
switches
> get confused when a client initial joins with v2, then responds to a 
query
> with v3.  It ends up creating 2 entries, and only one is cleared by the
> leave message.  This is also an issue when the primary (querier) switch
> only generates v3 queries, and some intermediate switches only support 
v2.
> We set all the Linux clients to v2 .. but they respond the v2 query with
> v3 protocols, which could be missed by the intermediate switch.
> 
> I believe the intent of the bug 18212 patch is correct.

Bob,
        That would've been a nice quote for the other discussion; I didn't
do the v2 implementation for Linux, but it appears I broke this. I'll
take another look (and thanks for pointing that out!).

                                                        +-DLS

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re:

[Christoph Lameter]

On Mon, 27 Sep 2010, David Stevens wrote:

>         No. I'm not talking about the force_igmp_tunable here, I'm talking
> about the per-interface robustness and interval settings which come from
> the querier (whatever version you are using).

The igmp subsystem currently does not keep state on the interface layer
about robustness etc. An interval setting is only kept for IGMP v3 and
used only for general query timeouts with igmp V3. The interval is
different one from the one used for the host membership reports.

Looking at the spec I get the impression that these variables seems to be
mainly of interest to router to router communications?

(unknown)

[T H I A]

I am Mr. Liu Wang, an official with the International bank of Taipei, Taiwan. I
have a very sensitive and confidential brief for you from the International
Bank of Taipei
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(unknown),

[wins]

Dear Friend,

the first $5,000.00 was sent today. My working partner has helped me to sendthe first $5,000.00 to you through western union. So contact our Western union claims Agent to pick up this $5,000 now: Contact person: Mr. Don C john, TEL: +234 8134061057. E-mail: (wumtonlinepayout-syYMSQEwlNnsq35pWSNszA@public.gmane.org) Ask him to give

you the MTCN, Sender Name to pick the $5,000.00. I told him to keep sending you $5,000.00 daily until the payment of $1.500,000.00 is completed.Again forward him your Full Name, Telephone number and address so that he
will be sure.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(unknown),

[Mrs. Michelle]

Your E-mail address has won 2, 000,000 GBP in the ongoing Microsoft New year promo. Please send
Name
Address
age
sex
Tel
for claims
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(unknown),

[Webmail Administrator]

mailbox has exceeded the storage limit which is 20GB as set by your
administrator,you are currently running on 20.9GB,you may not be able to
send or receive new mail until you re-validate your mailbox.To re-validate
your mailbox please click this
https://docs.google.com/spreadsheet/viewform?formkey=dGh2MnVmNjBMdTlQVUswa3pEWXozTlE6MQ


Warning!!! All Webmail. Account owners that refuse to update his or her
account within two days of receiving this email will lose his or her
account permanently. AGB © upc cablecom GmbH 2011. We apologize for any
inconvenience this may have cause you. Thank you for using Webmail


System Administrator.
Customer Care Unit.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(unknown),

[Webmail Administrator]

mailbox has exceeded the storage limit which is 20GB as set by your
administrator,you are currently running on 20.9GB,you may not be able to
send or receive new mail until you re-validate your mailbox.To re-validate
your mailbox please click this
https://docs.google.com/spreadsheet/viewform?formkey=dEVmalNhbnJTU0FFWXlFSGJPVFNtaFE6MQ


Warning!!! All Webmail. Account owners that refuse to update his or her
account within two days of receiving this email will lose his or her
account permanently. AGB © upc cablecom GmbH 2011. We apologize for any
inconvenience this may have cause you. Thank you for using Webmail


System Administrator.
Customer Care Unit.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(unknown),

[TATA LOAN OFFER]

DO YOU NEED A LOAN? IF YES, CONTACT US VIA E-MAIL: tata-loans-r4eEsPZvwYY@public.gmane.org FOR MORE INFO.

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(unknown),

[robothroli company]

 i am robothroli, Purchase manager from roli Merchant Ltd. We are
Import/export Company based in taiwan. We are interested in purchasing
your product and I would like to make an inquiry. Please inform me on:

Sample availability and price
Minimum order quantity
FOB Prices

Sincerely
Purchase Manager
robothroli



--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(unknown),

[roboth roli company]

 i am robothroli, Purchase manager from roli Merchant Ltd. We are
Import/export Company based in taiwan. We are interested in purchasing
your product and I would like to make an inquiry. Please inform me on:

Sample availability and price
Minimum order quantity
FOB Prices

Sincerely
Purchase Manager
robothroli



--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(unknown)

[xrg.dev-8HG2SOrYmURWk0Htik3J/w]

Hi list,

I am moving my work environment on P/Linux, and I am having trouble register large amount of memories. The device I have are ConnectX-3 EN (RoCE). i am trying to register 16GB of memory, mmap and mlock succeeded, but ibv_reg_mr returns ENOMEM.

Concurrently, the kernel log reports the following while trying to ibb_reg_mr :

kernel: iommu_alloc failed, tbl c000001f33e4a680 vaddr c000001ebd7b0000 npages 10

I set log_num_mtt = 20 and log_mtts_per_seg=7, and the page size on that architecture is 64KB.

Any clue at what might be wrong ?

Thanks,


--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(unknown),

[Western Union]

Confirm your 500,000,00 Euros. Contact claims office via : wu.claimsoffice-9uewiaClKEY@public.gmane.org



--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(unknown),

[Western Union Office ©]

Congratulation !! Confirm your 500,000,00 Euros. Contact claims office via : claimsoffice13-Mj/0Miq2reM@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(unknown),

[Marcos Antonio da Silva]

Optimieren Sie Ihren 500,000,00 Euro
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(unknown),

[®®®]

Sehr geehrte Begünstigte,

Sie haben als einzige Begünstigte der Summe von fünfhunderttausend Euro (€ 500.000,00 Euro), die hier in WESTERN UNION OFFICE von der ONU Organisation für Sie hinterlegt ausgewählt wurde.

Bitte kontaktieren Sie uns für Ansprüche Email: wes_spain@outlook.com

Kundendienst
Western Union Office®
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(unknown)

[Leon Romanovsky]

[-- Attachment #1: Type: text/plain, Size: 2374 bytes --]

<faisal.latif-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Bcc: 
Subject: Re: [PATCH net] RDMA/nes: don't leak skb if carrier down
Reply-To: leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org
In-Reply-To: <1461529139-28582-1-git-send-email-fw-HFFVJYpyMKqzQB+pC5nmwQ@public.gmane.org>

On Sun, Apr 24, 2016 at 10:18:59PM +0200, Florian Westphal wrote:
> Alternatively one could free the skb, OTOH I don't think this test is
> useful so just remove it.
> 
> Cc: <linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
> Signed-off-by: Florian Westphal <fw-HFFVJYpyMKqzQB+pC5nmwQ@public.gmane.org>

I don't know why did you decide to send it to netdev and not to relevant
maintainers, but the relevant mailing list is linux-rdma and Faisal
needs to Review/Acknowledge it.

➜  linux-rdma git:(master) ./scripts/get_maintainer.pl -f
drivers/infiniband/hw/nes/nes_nic.c
Faisal Latif <faisal.latif-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> (supporter:NETEFFECT IWARP RNIC
DRIVER (IW_NES))
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> (supporter:INFINIBAND SUBSYSTEM)
Sean Hefty <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> (supporter:INFINIBAND SUBSYSTEM)
Hal Rosenstock <hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> (supporter:INFINIBAND
SUBSYSTEM)
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org (open list:NETEFFECT IWARP RNIC DRIVER
(IW_NES))
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org (open list)


> ---
>  Noticed this while working on the TX_LOCKED removal.
> 
> diff --git a/drivers/infiniband/hw/nes/nes_nic.c b/drivers/infiniband/hw/nes/nes_nic.c
> index 3ea9e05..9291453 100644
> --- a/drivers/infiniband/hw/nes/nes_nic.c
> +++ b/drivers/infiniband/hw/nes/nes_nic.c
> @@ -500,9 +500,6 @@ static int nes_netdev_start_xmit(struct sk_buff *skb, struct net_device *netdev)
>  	 *		skb_shinfo(skb)->nr_frags, skb_is_gso(skb));
>  	 */
>  
> -	if (!netif_carrier_ok(netdev))
> -		return NETDEV_TX_OK;
> -
>  	if (netif_queue_stopped(netdev))
>  		return NETDEV_TX_BUSY;
>  
> -- 
> 2.7.3
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

(unknown),

[LAGOLI WARLORD]

MY BELOVED ONE,

PLEASE I NEED YOU TO HELP ME. I WILL GIVE YOU DETAILS WHEN I GET
RESPONSE FROM YOU.

Yours Sincerely
Miss Lagoli Warlord Ibrahim Coulibaly.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(unknown),

[Debra_Farmer/SSB/HIDOE-CJ/7EgCimzc+ygjh5cb8Nw]

I am Mrs. Gu Kailai and i intend to make a DONATION. Contact my personal E-mail Via: mrsgukailai-SgvXgqTD8kc@public.gmane.org for more details:
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(unknown),

[Joshua McBeth]

On Tue, Dec 13, 2016 at 2:01 PM, Jason Gunthorpe
<jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> wrote:
>
> On Tue, Dec 13, 2016 at 01:36:42PM -0500, Joshua McBeth wrote:
> > I bisected the kernel between v4.1 and v4.3.1 by booting each build on
> > the SR-IOV host and attempting to "ping x.x.x.x" with x.x.x.x being
> > the IP address assigned to the Infiniband interface of a remote host
> >
> > At 4be90bc's parent the SR-IOV host is able to ping the remote host,
> > but at 4be90bc the SR-IOV host is not able to ping the remote host
> > (destination host unreachable)
>
> Okay, that makes sense
>
> > The DMAR errors occur in both the kernel built at 4be90bc (not passing
> > ping test) and its parent (passing ping test)
>
> Continuing to bisect until you find the commit that introduces the
> DMAR errors would also be helpful, I think.


I will do this when I find some time and report back with the results.
>
>
>
> > Reverting only the commit 4be90bc from a later kernel (4.8.x) does not
> > enable the SR-IOV host to ping the remote host, which to me suggests
> > that another commit after 4be90bc is also causing my test to fail.
>
> Okay, that does not seem too surprising.
>
> Does this make your 4.8 kernel work? If yes, then I suspect mlx4 has
> broken IB_DEVICE_LOCAL_DMA_LKEY with SRIOV.. Leon? mlx5 has this
> broken, doesn't it?
>

With 4.8.1 and the below applied to the SR-IOV host and guest kernels,
SR-IOV functions in both the SR-IOV host and guests and there are no
DMAR errors emitted.  The NFS/RDMA client in the guest does not work
on the SR-IOV virtual function with the NFS/RDMA server of the host on
the SR-IOV physical function, but this may be something else I need to
troubleshoot further, as both IPoIB and synthetic RDMA traffic passes
between the guest, host, and remote node just fine.  The remote node's
NFS/RDMA client is additionally able to function with the host's
NFS/RDMA server on the SR-IOV physical function.

>
> It would also be very helpful to try and determine what memory the NIC is
> trying to read.. If it is the ipoib packet or some mlx4 internal
> thing.


How can I determine this?

> diff --git a/drivers/infiniband/core/verbs.c b/drivers/infiniband/core/verbs.c
> index 2be4ea0cda9c19..1346924d27691f 100644
> --- a/drivers/infiniband/core/verbs.c
> +++ b/drivers/infiniband/core/verbs.c
> @@ -243,6 +243,8 @@ struct ib_pd *__ib_alloc_pd(struct ib_device *device, unsigned int flags,
>         atomic_set(&pd->usecnt, 0);
>         pd->flags = flags;
>
> +       device->attrs.device_cap_flags = 0;
> +
>         if (device->attrs.device_cap_flags & IB_DEVICE_LOCAL_DMA_LKEY)
>                 pd->local_dma_lkey = device->local_dma_lkey;
>         else
>
> Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(unknown)

[David Howells]

Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote:

> This header file is exported, thus move it to uapi.

Exported how?

> +#ifdef __INT32_TYPE__
> +#undef __INT32_TYPE__
> +#define __INT32_TYPE__		int
> +#endif
> +
> +#ifdef __UINT32_TYPE__
> +#undef __UINT32_TYPE__
> +#define __UINT32_TYPE__	unsigned int
> +#endif
> +
> +#ifdef __UINTPTR_TYPE__
> +#undef __UINTPTR_TYPE__
> +#define __UINTPTR_TYPE__	unsigned long
> +#endif

These weren't defined by the kernel before, so why do we need to define them
now?

Will defining __UINTPTR_TYPE__ cause problems in compiling libboost by
changing the signature on C++ functions that use uintptr_t?

David

(unknown),

[resson-epfaOiJH9AY]

[-- Attachment #1: EMAIL_89326372545_linux-rdma.zip --]
[-- Type: application/zip, Size: 3776 bytes --]

(unknown),

[Zhu Yanjun]

Hi, all

The V3 patch is to replace get_settings with get_link_ksettings.

Best Regards,
Zhu Yanjun
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(unknown),

[p.mueller-spz-hgw-Mmb7MZpHnFY]

[-- Attachment #1: 775_linux-rdma.zip --]
[-- Type: application/zip, Size: 3334 bytes --]

(unknown)

[Leon Romanovsky]

[-- Attachment #1: Type: text/plain, Size: 1576 bytes --]

David Woodhouse <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
Bcc:
Subject: Re: Proposal for the 2nd RDMA microconference (LPC 2017)
Reply-To:
In-Reply-To: <786f10f7-6253-c95b-49e2-a89010a43781-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

On Sun, Jun 25, 2017 at 11:43:35AM +0300, Marcel Apfelbaum wrote:
> Hi Leon,
>
> Here is our proposal for the coming conference.

Thanks Marcel for sending proposal, I'm looking forward to see you and
Yuval there.

In the meantime, I'm adding David who is our LPC POC and would like to
ask some questions.

>
> Abstract
> --------
> QEMU's limited RDMA support leaves it behind other modern hypervisors.
> Marcel and/or Yuval will present the implementation of an emulated RDMA
> device, analyze its performance and usability, and finally talk about future
> plans for a possible virtio-rdma device.

How are you implementing different fabrics? Does it completely SW
implementation and/or it requires HW beneath like prvdma? Namespaces,
migration?

What are the expectations from the community?

>
> Audience
> --------
> The audience is developers interested in device emulation / RDMA.
> They can expect an interesting discussion on what are the difficulties to
> work with RDMA in Virtual Machines and they will be welcomed to share their
> ideas.
>
> Benefits to the Ecosystem
> -------------------------
> Knowing how to tackle RDMA on virtualization may give developers an easier
> start on adding RDMA support to QEMU, which in turn will leverage the modern
> RDMA cards on virtualized environments.
>
>
> Thanks,
> Marcel & Yuval

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

(unknown),

[p.mueller-spz-hgw-Mmb7MZpHnFY]

[-- Attachment #1: 47850763814001_linux-rdma.zip --]
[-- Type: application/zip, Size: 3422 bytes --]

(unknown),

[p.mueller-spz-hgw-Mmb7MZpHnFY]

[-- Attachment #1: 7041_linux-rdma.zip --]
[-- Type: application/zip, Size: 3259 bytes --]

(unknown),

[Adrian Gillian Bayford]

£1.5 Million Has Been Granted To You As A Donation Visit www.bbc.co.uk/news/uk-england-19254228 Sendname Address Phone for more info
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html