Re: [net-next v5 1/6] net: marvell: prestera: Add driver for Prestera family ASIC devices

[Vadym Kochan <vadym.kochan@plvision.eu>]

On Tue, Aug 25, 2020 at 05:20:03PM -0700, David Miller wrote:
> From: Vadym Kochan <vadym.kochan@plvision.eu>
> Date: Tue, 25 Aug 2020 15:20:08 +0300
> 
> > +int prestera_dsa_parse(struct prestera_dsa *dsa, const u8 *dsa_buf)
> > +{
> > +	__be32 *dsa_words = (__be32 *)dsa_buf;
> > +	enum prestera_dsa_cmd cmd;
> > +	u32 words[4] = { 0 };
> > +	u32 field;
> > +
> > +	words[0] = ntohl(dsa_words[0]);
> > +	words[1] = ntohl(dsa_words[1]);
> > +	words[2] = ntohl(dsa_words[2]);
> > +	words[3] = ntohl(dsa_words[3]);
> 
> All 4 elements of words[] are explicitly and unconditionally set to something,
> so you don't need the "= { 0 }" initializer.

Right, will fix it.

> 
> > +	INIT_LIST_HEAD(&sw->port_list);
> 
> What locking protects this list?
> 

Initially there was (in RFC patch set), not locking, but _rcu list API
used, because the port list is modified only by 1 writer when creating
the port or deleting it on switch uninit (the really theoretical case
which might happen is that event might be received at that time which
causes to loop over this list to find the port), as I understand
correctly list_add_rcu is safe to use with no additional locking if there is 1
writer and many readers ? So can I use back this approach ?

> > +	new_skb = alloc_skb(len, GFP_ATOMIC | GFP_DMA);
> > +	if (!new_skb)
> > +		goto err_alloc_skb;
> 
> This seems very costly to do copies on every packet.  There should be
> something in the dma_*() API that would allow you to avoid this.

There is a limitation on the DMA range. Current device can't handle
whole ZONE_DMA range, so there is a "backup" mechanism which copies the
entire packet if the mapping was failed or if the packet's mapped
address is out of this range, this is done on both rx and tx directions.

> 
> And since you just need the buffer to DMA map it into the device,
> allocating an entire SKB object is overkill.  You can instead just
> allocate a ring of TX bounce buffers once, and then you just copy
> each packet there.  No allocations per packet.

Yes, this makes sense, thanks.