netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Hemminger <shemminger@osdl.org>
To: "Divy Le Ray <divy@chelsio.com>" <divy@chelsio.com>
Cc: jeff@garzik.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/10] cxgb3 - main header files
Date: Fri, 17 Nov 2006 12:49:02 -0800	[thread overview]
Message-ID: <20061117124902.7e69af2e@freekitty> (raw)
In-Reply-To: <20061117202320.25878.26769.stgit@colfax2.asicdesigners.com>


> +
> +struct work_struct;
> +struct dentry;


Why do you need these extra forward declarations?

...

> +
> +struct sge_rspq {                   /* state for an SGE response queue */
> +	unsigned int credits;       /* # of pending response credits */
> +	unsigned int size;          /* capacity of response queue */
> +	unsigned int cidx;          /* consumer index */
> +	unsigned int gen;           /* current generation bit */
> +	unsigned int polling;       /* is the queue serviced through NAPI? */
> +	unsigned int holdoff_tmr;   /* interrupt holdoff timer in 100ns */
> +	unsigned int next_holdoff;  /* holdoff time for next interrupt */
> +	struct rsp_desc *desc;      /* address of HW response ring */
> +	dma_addr_t   phys_addr;     /* physical address of the ring */
> +	unsigned int cntxt_id;      /* SGE context id for the response q */
> +	spinlock_t   lock;          /* guards response processing */
> +	struct sk_buff *rx_head;    /* offload packet receive queue head */
> +	struct sk_buff *rx_tail;    /* offload packet receive queue tail */

Why not use sk_buff_head?

...

> +	/*
> +	 * Dummy netdevices are needed when using multiple receive queues with
> +	 * NAPI as each netdevice can service only one queue.
> +	 */
> +	struct net_device *dummy_netdev[SGE_QSETS - 1];
>

Rather than abusing, NAPI with multiple receive queue's why not do it
by either:
	1) changing NAPI to have multiple receive contexts
	2) or use your own tasklet and processing.

> +	struct dentry *debugfs_root;
> +
> +	struct semaphore mdio_lock;
> +	spinlock_t stats_lock;
> +	spinlock_t work_lock;
> +};
> +
> +#define MDIO_LOCK(adapter) down(&(adapter)->mdio_lock)
> +#define MDIO_UNLOCK(adapter) up(&(adapter)->mdio_lock)

Please don't wrap locks


> +static inline u32 t3_read_reg(adapter_t *adapter, u32 reg_addr)
> +{
> +	u32 val = readl(adapter->regs + reg_addr);
> +
> +	CH_DBG(adapter, MMIO, "read register 0x%x value 0x%x\n", reg_addr,
> +	       val);
> +	return val;
> +}
> +
> +static inline void t3_write_reg(adapter_t *adapter, u32 reg_addr, u32 val)
> +{
> +	CH_DBG(adapter, MMIO, "setting register 0x%x to 0x%x\n", reg_addr,
> +	       val);
> +	writel(val, adapter->regs + reg_addr);
> +}

This kind of wrapper makes sense.

> +static inline int t3_os_pci_save_state(adapter_t *adapter)
> +{
> +	return pci_save_state(adapter->pdev);
> +}

Please don't add bogus OS independent wrappers. It makes it harder for later
maintenance.

> +static inline int t3_os_pci_restore_state(adapter_t *adapter)
> +{
> +	return pci_restore_state(adapter->pdev);
> +}
> +
> +static inline void t3_os_pci_write_config_4(adapter_t *adapter, int reg,
> +					    u32 val)
> +{
> +	pci_write_config_dword(adapter->pdev, reg, val);
> +}
> +
> +static inline void t3_os_pci_read_config_4(adapter_t *adapter, int reg,
> +					   u32 *val)
> +{
> +	pci_read_config_dword(adapter->pdev, reg, val);
> +}
> +
> +static inline void t3_os_pci_write_config_2(adapter_t *adapter, int reg,
> +					    u16 val)
> +{
> +	pci_write_config_word(adapter->pdev, reg, val);
> +}
> +
> +static inline void t3_os_pci_read_config_2(adapter_t *adapter, int reg,
> +					   u16 *val)
> +{
> +	pci_read_config_word(adapter->pdev, reg, val);
> +}
> +
> +static inline int t3_os_find_pci_capability(adapter_t *adapter, int cap)
> +{
> +	return pci_find_capability(adapter->pdev, cap);
> +}
> +
> +static inline const char *adapter_name(adapter_t *adapter)
> +{
> +	return adapter->name;
> +}
> +
> +static inline const char *port_name(adapter_t *adapter, unsigned int port_idx)
> +{
> +	return adapter->port[port_idx].dev->name;
> +}

Why not do this inline.

> +static inline void t3_os_set_hw_addr(adapter_t *adapter, int port_idx,
> +				     u8 hw_addr[])
> +{
> +	memcpy(adapter->port[port_idx].dev->dev_addr, hw_addr, ETH_ALEN);
> +#ifdef ETHTOOL_GPERMADDR
> +	memcpy(adapter->port[port_idx].dev->perm_addr, hw_addr, ETH_ALEN);
> +#endif
> +}

Another bogus wrapper.

> +/*
> + * We use the spare atalk_ptr to map a net device to its SGE queue set.
> + * This is a macro so it can be used as l-value.
> + */
> +#define dev2qset(netdev) ((netdev)->atalk_ptr)

That looks a bad idea.

> +
> +#define OFFLOAD_DEVMAP_BIT 15
> +
> +#define tdev2adap(d) container_of(d, struct adapter, tdev)
> +
> +static inline int offload_running(adapter_t *adapter)
> +{
> +	return test_bit(OFFLOAD_DEVMAP_BIT, &adapter->open_device_map);
> +}
> +
> +int t3_offload_tx(struct t3cdev *tdev, struct sk_buff *skb);

What kind of offload?  You remember TOE was rejected.


> +#define promisc_rx_mode(rm)  ((rm)->dev->flags & IFF_PROMISC)
> +#define allmulti_rx_mode(rm) ((rm)->dev->flags & IFF_ALLMULTI)


Yet another high maintenance wrapper


> +struct sg_ent {                   /* SGE scatter/gather entry */
> +	u32 len[2];
> +	u64 addr[2];
> +};

Shouldn't 2 be NPORTS or somthing.

  reply	other threads:[~2006-11-17 20:50 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-17 20:23 [PATCH 1/10] cxgb3 - main header files Divy Le Ray <divy@chelsio.com>
2006-11-17 20:49 ` Stephen Hemminger [this message]
2006-11-17 21:48   ` Roland Dreier
2006-11-18 17:25 ` Jan Engelhardt
  -- strict thread matches above, loose matches on Subject: below --
2006-12-04 19:44 Divy Le Ray
2006-12-08  3:26 Divy Le Ray
2006-12-14  5:41 Divy Le Ray
2006-12-20 12:41 Divy Le Ray
2006-12-26 20:57 ` Jeff Garzik
2006-12-27  8:52   ` Divy Le Ray
2006-12-27  9:03     ` Arjan van de Ven
2007-01-09 10:19   ` Divy Le Ray
2007-01-09 10:28     ` Jeff Garzik
2007-01-09 13:38       ` Steve Wise
2007-01-09 13:57         ` Michael S. Tsirkin
2007-01-09 14:46           ` Steve Wise
2007-01-09 18:29           ` Caitlin Bestler
2007-01-09 16:28       ` Roland Dreier
2007-01-09 16:41         ` Jeff Garzik
2007-01-09 17:09           ` Roland Dreier
2007-01-19  3:05     ` Jeff Garzik
2006-12-22  7:20 Divy Le Ray

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=20061117124902.7e69af2e@freekitty \
    --to=shemminger@osdl.org \
    --cc=divy@chelsio.com \
    --cc=jeff@garzik.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    /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 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).