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.
next prev parent 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).