> Andi Kleen wrote:
>
> > It makes sense to provide an API for the NIC driver to allocate skb
> > from the
> > *right* mempool. This way if I have plenty of hw rings and/or can
> > allow myself a luxury to associate 1-to-1 connection and
> ring, there's
> > a nice and clean memory management model. Even NICs that
> have only few
> > rings could use this - for critical (e.g., storage) connections.
>
> It wont work - I can guarantee you that if you add a limit
> like "we only support 8 iscsi connections max" then
> users/customers will raise hell because it does not fit their
> networks.
>
Something a bit more intelligent, like: we only support 7 resource-protected
(a.k.a. critical) iSCSI connection, and we use one remaining ring for the
rest iSCSI, TCP, UDP, etc. traffic. The 7 iSCSI connections could be quite a
bit, in terms of LUNs, and just enough for a customer to feel "protected" in
a sense that unrelated receive burst starves storage traffic to death. Note
that "8 rings" here is just an example; as time goes by the number of hw
receive rings and the hw ability to intelligently classify and steer traffic
onto these rings will only increase.
Alex
|