Re: [Xen-devel] [PATCH net-next 2/2] xen-netback: avoid allocating variable size array on stack

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Wed, May 01, 2013 at 11:32:41AM +0100, Ian Campbell wrote:
> On Tue, 2013-04-30 at 17:50 +0100, Wei Liu wrote:
> > Tune xen_netbk_count_requests to not touch working array beyond limit, so 
> > that
> > we can make working array size constant.
> 
> Is this really correct when max_skb_slots > XEN_NETIF_NR_SLOTS_MIN?
> Seems like we would either overrun the array or drop frames which
> max_skb_slots suggests we should accept?
> 

So the max_skb_slots for now is the standard to determine whether a
guest is malicious, not the maximum slots we can process.

> If anything the array would need to be size by XEN_NETIF_NR_SLOTS_MAX
> which a) doesn't exist and b) would be worse than using max_skb_slots. I
> wouldn't be particularly averse to enforcing some sensible maximum on
> max_skb_slots.
> 

A sensible one is tricky, but presumably we would need it sooner or
later.

> Other options:
> 
> Handle batches of work in <max_skb_slots sized bundles, but that gets
> complex when you consider the case of an skb which crosses multiple such
> bundles.
> 
> xen_netbk_get_requests() copes the tx req again into the pending_tx_info
> -- any way we can arrange for this to just happen right in the first
> place?
> 

Isn't the point of having xen_netbk_count_requests to drop malformed
packets before wasting any effort processing them?

In the current design pending_tx_info only have valid tx request.

> Or perhaps it is time for each vif to allocate a page of its own to
> shadow the shared ring, and remove that field from pending_tx_info?
> (which isn't really a net increase in memory usage, but might simplify
> some things?)
> 

Not sure about this, will need to look into it.


Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel