From: "Saleem, Shiraz" <email@example.com> To: Leon Romanovsky <firstname.lastname@example.org>, "Ertman, David M" <email@example.com> Cc: "firstname.lastname@example.org" <email@example.com>, "firstname.lastname@example.org" <email@example.com>, "firstname.lastname@example.org" <email@example.com>, "Nguyen, Anthony L" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "Brandeburg, Jesse" <email@example.com>, "firstname.lastname@example.org" <email@example.com>, "firstname.lastname@example.org" <email@example.com>, "firstname.lastname@example.org" <email@example.com>, "Williams, Dan J" <firstname.lastname@example.org>, "Singhai, Anjali" <email@example.com>, "Parikh, Neerav" <firstname.lastname@example.org>, "Samudrala, Sridhar" <email@example.com> Subject: RE: [PATCH RESEND net] ice: Correctly deal with PFs that do not support RDMA Date: Mon, 13 Sep 2021 15:49:43 +0000 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <YTsjDsFbBggL2X/8@unreal> > Subject: Re: [PATCH RESEND net] ice: Correctly deal with PFs that do not > support RDMA > > On Thu, Sep 09, 2021 at 08:12:23AM -0700, Dave Ertman wrote: > > There are two cases where the current PF does not support RDMA > > functionality. The first is if the NVM loaded on the device is set to > > not support RDMA (common_caps.rdma is false). The second is if the > > kernel bonding driver has included the current PF in an active link > > aggregate. > > > > When the driver has determined that this PF does not support RDMA, > > then auxiliary devices should not be created on the auxiliary bus. > > This part is wrong, auxiliary devices should always be created, in your case it will > be one eth device only without extra irdma device. It is worth considering having an eth aux device/driver but is it a hard-and-fast rule? In this case, the RDMA-capable PCI network device spawns an auxiliary device for RDMA and the core driver is a network driver. > > Your "bug" is that you mixed auxiliary bus devices with "regular" ones and created > eth device not as auxiliary one. This is why you are calling to auxiliary_device_init() > for RDMA only and fallback to non-auxiliary mode. It's a design choice on how you carve out function(s) off your PCI core device to be managed by auxiliary driver(s) and not a bug. Shiraz
next prev parent reply other threads:[~2021-09-13 15:50 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-09-09 15:12 Dave Ertman 2021-09-10 9:19 ` Leon Romanovsky 2021-09-13 15:49 ` Saleem, Shiraz [this message] 2021-09-13 16:07 ` Ertman, David M 2021-09-14 3:16 ` Leon Romanovsky 2021-09-14 3:10 ` Leon Romanovsky 2021-09-24 14:10 ` Jason Gunthorpe
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='RE: [PATCH RESEND net] ice: Correctly deal with PFs that do not support RDMA' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).