All of lore.kernel.org
 help / color / mirror / Atom feed
From: Aviad Krawczyk <aviad.krawczyk@huawei.com>
To: Francois Romieu <romieu@fr.zoreil.com>
Cc: <davem@davemloft.net>, <linux-kernel@vger.kernel.org>,
	<netdev@vger.kernel.org>, <bc.y@huawei.com>,
	<victor.gissin@huawei.com>, <zhaochen6@huawei.com>,
	<tony.qu@huawei.com>
Subject: Re: [PATCH V2 net-next 01/21] net-next/hinic: Initialize hw interface
Date: Tue, 25 Jul 2017 17:50:38 +0300	[thread overview]
Message-ID: <01800b7a-c11d-980f-0e5e-d4684eaa0f2a@huawei.com> (raw)
In-Reply-To: <20170724230318.GA26260@electric-eye.fr.zoreil.com>

Hi,

hinic_remove - you are right, it is over safe code. We can remove it without
any crash. This case has never happened.

void * - I meant the problem is not in rq or sq, it can be in wq. But you confirmed
that it is ok to use union instead of the void* in wq. So, we will use union in wq.c
and in rq - rq_wqe and in sq - sq_wqe.

module_pci_driver - is not used in other drivers in the same segments, it is necessary?

Thanks,
Aviad


On 7/25/2017 2:03 AM, Francois Romieu wrote:
> Aviad Krawczyk <aviad.krawczyk@huawei.com> :
> [...]
>> hinic_remove - If insmod failed and someone calls rmmod, we will get a
>> crash because the resource are already free. Therefore we test if the
>> device exists, please tell me if you meant to something different
> 
> The module won't even proceed through the pci_driver remove method if
> the probe method failed. See drivers/pci/bus.c::pci_bus_add_device and
> track 'dev->is_added'. You don't need to believe me: try it.
> 
> I have no idea where your crash comes from but something does not
> look quite right.
> 
> (use module_pci_driver() to save some boilerplate code btw)
> 
> [...]
>> The priv data is in type void * because the
>> caller can use any struct that it wants, like the priv data in Linux
>> (netdev, irq, tasklet, work..) -
> 
> I disagree. A driver is a piece of glue between hardware and software.
> It fills a kernel's contract. It is not supposed to introduce opaque
> data (even if it's hard to resist).
> 
>> we can change it but if we will pass different struct
>> in the future, we will have to change the prototype of the functions.
> 
> It's fine. If I do something wrong - and at some point I will - I'd
> rather have it detected at compile time. Nobody wants to waste precious
> hardware lab testing time because of excess void *.
> 
>> According to the other void *:
>> The wq struct is used for cmdq, sq and rq. Therefore the wqe is in type
>> void *. There are 4 operations get_wqe, write_wqe, read_wqe and put_wqe - there
>> is no option that one function will be fed with a wrong pointer because the caller
>> should use what it got in get_wqe function.
>>
>> When something is used as multiple types, it can be used as void * or union.
>> Usually, I would prefer union. But, in this case if we will use union, maybe
>> there is a chance of using the wrong wqe type in the wrong work queue type.
> 
> union * will at least catch being fed a wrong type. void * won't notice.
> 
> Let's take a practical example: hinic_sq_get_sges.
> 
> void hinic_sq_get_sges(void *wqe, struct hinic_sge *sges, int nr_sges)
>                        ^^^^^^^^^
> {
>         struct hinic_sq_wqe *sq_wqe = (struct hinic_sq_wqe *)wqe;
> 
> 
> static void free_all_tx_skbs(struct hinic_txq *txq)
> {
>         struct hinic_dev *nic_dev = netdev_priv(txq->netdev);
>         struct hinic_sq *sq = txq->sq;
>         struct hinic_sq_wqe *wqe;
> [...]
>                 hinic_sq_get_sges(wqe, txq->free_sges, nr_sges);
> 
> 
> static int free_tx_poll(struct napi_struct *napi, int budget)
> {
> [...]
>         struct hinic_sq_wqe *wqe;
> [...]
>                 hinic_sq_get_sges(wqe, txq->free_sges, nr_sges);
> 
> 
> Why is it:
> 
> void hinic_sq_get_sges(void *wqe, ...
> 
> instead of:
> 
> void hinic_sq_get_sges(struct hinic_sq_wqe *wqe, ...
> 
> Because of a future change ?
> 

  reply	other threads:[~2017-07-25 14:51 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-19  9:18 [PATCH V2 net-next 00/21] Huawei HiNIC Ethernet Driver Aviad Krawczyk
2017-07-19  9:18 ` [PATCH V2 net-next 01/21] net-next/hinic: Initialize hw interface Aviad Krawczyk
2017-07-19 22:27   ` Francois Romieu
2017-07-23 10:30     ` Aviad Krawczyk
2017-07-24 23:03       ` Francois Romieu
2017-07-25 14:50         ` Aviad Krawczyk [this message]
2017-07-25 20:02           ` Francois Romieu
2017-07-26 12:48             ` Aviad Krawczyk
2017-07-19  9:19 ` [PATCH V2 net-next 02/21] net-next/hinic: Initialize hw device components Aviad Krawczyk
2017-07-19  9:19 ` [PATCH V2 net-next 03/21] net-next/hinic: Initialize api cmd resources Aviad Krawczyk
2017-07-19  9:19 ` [PATCH V2 net-next 04/21] net-next/hinic: Initialize api cmd hw Aviad Krawczyk
2017-07-19  9:19 ` [PATCH V2 net-next 05/21] net-next/hinic: Add management messages Aviad Krawczyk
2017-07-19  9:19 ` [PATCH V2 net-next 06/21] net-next/hinic: Add api cmd commands Aviad Krawczyk
2017-07-19  9:19 ` [PATCH V2 net-next 07/21] net-next/hinic: Add aeqs Aviad Krawczyk
2017-07-19  9:19 ` [PATCH V2 net-next 08/21] net-next/hinic: Add port management commands Aviad Krawczyk
2017-07-19  9:19 ` [PATCH V2 net-next 09/21] net-next/hinic: Add Rx mode and link event handler Aviad Krawczyk
2017-07-19  9:19 ` [PATCH V2 net-next 10/21] net-next/hinic: Add logical Txq and Rxq Aviad Krawczyk
2017-07-19  9:19 ` [PATCH V2 net-next 11/21] net-next/hinic: Add wq Aviad Krawczyk
2017-07-19  9:19 ` [PATCH V2 net-next 12/21] net-next/hinic: Add qp resources Aviad Krawczyk
2017-07-19 23:13   ` David Miller
2017-07-23 10:07     ` Aviad Krawczyk
2017-07-19  9:19 ` [PATCH V2 net-next 13/21] net-next/hinic: Set qp context Aviad Krawczyk
2017-07-19  9:19 ` [PATCH V2 net-next 14/21] net-next/hinic: Initialize cmdq Aviad Krawczyk
2017-07-19  9:19 ` [PATCH V2 net-next 15/21] net-next/hinic: Add ceqs Aviad Krawczyk
2017-07-19  9:19 ` [PATCH V2 net-next 16/21] net-next/hinic: Add cmdq commands Aviad Krawczyk
2017-07-19  9:19 ` [PATCH V2 net-next 17/21] net-next/hinic: Add cmdq completion handler Aviad Krawczyk
2017-07-19  9:19 ` [PATCH V2 net-next 18/21] net-next/hinic: Add Rx handler Aviad Krawczyk
2017-07-19  9:19 ` [PATCH V2 net-next 19/21] net-next/hinic: Add Tx operation Aviad Krawczyk
2017-07-19  9:19 ` [PATCH V2 net-next 20/21] net-next/hinic: Add ethtool and stats Aviad Krawczyk
2017-07-19 10:27   ` Joe Perches
2017-07-19 12:36     ` Aviad Krawczyk
2017-07-26 22:33       ` Andrew Lunn
2017-07-30  9:59         ` Aviad Krawczyk
2017-07-19  9:19 ` [PATCH V2 net-next 21/21] net-next/hinic: Add select_queue and netpoll Aviad Krawczyk
2017-07-19 11:34   ` Sergei Shtylyov
2017-07-19 12:41     ` Aviad Krawczyk

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 \
    --in-reply-to=01800b7a-c11d-980f-0e5e-d4684eaa0f2a@huawei.com \
    --to=aviad.krawczyk@huawei.com \
    --cc=bc.y@huawei.com \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=romieu@fr.zoreil.com \
    --cc=tony.qu@huawei.com \
    --cc=victor.gissin@huawei.com \
    --cc=zhaochen6@huawei.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.