> +#define DECLARE_PER_NET(type, name) \
> + extern __typeof__(type) __pernetname(name)
> +
> +#define EXPORT_PER_NET_SYMBOL(var) \
> + EXPORT_SYMBOL(__pernetname(var))
> +#define EXPORT_PER_NET_SYMBOL_GPL(var) \
> + EXPORT_SYMBOL_GPL(__pernetname(var))
>
do_net);
> + }
> +undone:
> + goto out;
> +}
> +
> +static void unregister_pernet_operations(struct pernet_operations *ops)
> +{
> + net_t net;
> +
> + list_del(&ops->list);
> + for_each_net(net)
> + if (ops->exit)
> + ops->exit(net);
> +}
> +
>
You should use RCU for this because registering/unregistering network
namespaces is obviously a much rarer occurrence than referencing them.
--
Stephen Hemminger <[EMAIL PROTECTED]>
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
ration
process is confusing (or could/should be done differently).
--
Stephen Hemminger <[EMAIL PROTECTED]>
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
in real
> life
> single copy should better.
>
The other alternative might be to make copy/checksum code smarter about using
fragments rather than allocating a large buffer. It should avoid second order
allocations (effective size > PAGESIZE).
--
Stephen Hemminger <[EMAIL PROTECTED]&g
es to use or not depending on the combinations available
> (which I think is pretty much your argument).
>
> Steve.
>
You might want to try ignoring the check in dev.c and testing
to see if there is a performance gain. It wouldn't be hard to test
a modified version and validate th
On Tue, 10 Oct 2006 16:43:30 +0200
"Michael S. Tsirkin" <[EMAIL PROTECTED]> wrote:
> Quoting r. Stephen Hemminger <[EMAIL PROTECTED]>:
> > Subject: Re: Dropping NETIF_F_SG since no checksum feature.
> >
> > On Mon, 9 Oct 2006 19:47:05 +0200
> &g
ffers is problematic on busy systems.
See lastest e1000 or sky2 that use frag_list.
> What are the helpers legal for fragmented skb?
Read the source. Setting up fragmented buffers has less helper
functions, but isn't that hard.
--
Stephen Hemminger <[EMAIL PROTECTED]>
ways unsigned long long. For
> example on ppc64, u64 is just unsigned long.
>
> - R.
The only safe way is to cast u64 to long long unsigned. and then use
either %Lu or %llu as format string. It means that on 64bit platforms
the u64 will end up getting extended, but the it&#
0/c2_rnic.c:552: warning: format '%llx' expects
> type 'long long unsigned int', but argument 4 has type 'dma_addr_t'
> drivers/infiniband/hw/amso1100/c2_alloc.c: In function 'c2_alloc_mqsp':
> drivers/infiniband/hw/amso1100/c2_alloc.c:117: warning: for
On Thu, 16 Mar 2006 17:24:41 -0500 (EST)
James Lentini <[EMAIL PROTECTED]> wrote:
>
> The ip(8) command has a bug when dealing with IPoIB link layer
> addresses. Specifically it does not correctly handle the addition of
> new entries in the neighbor/arp table. For example, this command will
>
On Tue, 07 Mar 2006 13:44:51 -0800
Matt Leininger <[EMAIL PROTECTED]> wrote:
> On Mon, 2006-03-06 at 19:13 -0800, Shirley Ma wrote:
> >
> > > More likely you are getting hit by the fact that TSO prevents the
> > congestion
> > window from increasing properly. This was fixed in 2.6.15 (around mid
On Tue, 7 Mar 2006 00:34:38 +0200
"Michael S. Tsirkin" <[EMAIL PROTECTED]> wrote:
> Hello, Dave!
> As you might know, the TSO patches merged into mainline kernel
> since 2.6.11 have hurt performance for the simple (non-TSO)
> high-speed netdevice that is IPoIB driver.
>
> This was discussed at le
st struct ib_cm_private_data_compare *src,
cosnt struct ib_cm_private_data_compare *dst)
Your data type names are getting too long
Also should infiniband exports be EXPORT_SYMBOL_GPL, to make
it clear that binary drivers for this are not allowed??
--
On 03 Oct 2005 14:48:44 -0400
Hal Rosenstock <[EMAIL PROTECTED]> wrote:
> netdevice.h: Add RDMA private pointer to the net_device structure
>
> Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]>
Who is going to use it? Is RDMA being submitted for code review?
--
Step
On Fri, 29 Jul 2005 15:59:03 -0400 (EDT)
James Lentini <[EMAIL PROTECTED]> wrote:
>
>
> On Fri, 29 Jul 2005, Woodruff, Robert J wrote:
>
> > Venkat wrote,
> >> If anyone attended any one of the summits (netconf or kernel) and
> >> would be great if they can shed some light on this discussion.
>
You might want to enforce that LLTX devices like tunnels need to have
no transmit queue (tx_queue_len == 0)?
I can run a test on 8 way with e1000 if it would help.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listin
;hard_start_xmit(), the driver typically turns hard
> > IRQs off anyways.
> [...]
> > Also, changing dev->xmit_lock to be IRQ disabling is not %100 trivial.
>
>
> Agreed on both counts...
But in the end it would be safer than the current LLTX usage in drivers
which s
o spin_lock_irqsave?
Any driver that assumes it is being called with irq's enabled in transmit
is probably already busted anyway.
--
Stephen Hemminger <[EMAIL PROTECTED]>
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
18 matches
Mail list logo
