* Re: [PATCH v3 04/11] SUNRPC: parametrize svc creation calls with portmapper flag
From: Stanislav Kinsbursky @ 2011-09-19 14:51 UTC (permalink / raw)
To: Jeff Layton
Cc: Trond.Myklebust@netapp.com, linux-nfs@vger.kernel.org,
Pavel Emelianov, neilb@suse.de, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, bfields@fieldses.org,
davem@davemloft.net
In-Reply-To: <20110919100811.0eaa39fe@tlielax.poochiereds.net>
19.09.2011 18:08, Jeff Layton пишет:
> On Tue, 13 Sep 2011 22:13:51 +0400
> Stanislav Kinsbursky<skinsbursky@parallels.com> wrote:
>
>> This new flag ("setup_rpcbind) will be used to detect, that new service will
>> send portmapper register calls. For such services we will create rpcbind
>> clients and remove all stale portmap registrations.
>> Also, svc_rpcb_cleanup() will be set as sv_shutdown callback for such services
>> in case of this field wasn't initialized earlier. This will allow to destroy
>> rpcbind clients when no other users of them left.
>>
>> Signed-off-by: Stanislav Kinsbursky<skinsbursky@parallels.com>
>>
>> ---
>> include/linux/sunrpc/svc.h | 2 ++
>> net/sunrpc/svc.c | 21 ++++++++++++++-------
>> 2 files changed, 16 insertions(+), 7 deletions(-)
>>
>> diff --git a/include/linux/sunrpc/svc.h b/include/linux/sunrpc/svc.h
>> index 223588a..528952a 100644
>> --- a/include/linux/sunrpc/svc.h
>> +++ b/include/linux/sunrpc/svc.h
>> @@ -402,11 +402,13 @@ struct svc_procedure {
>> * Function prototypes.
>> */
>> struct svc_serv *svc_create(struct svc_program *, unsigned int,
>> + int setup_rpcbind,
> ^^^
> Instead of adding this parameter, why not
> base this on the vs_hidden flag in the
> svc_version? IOW, have a function that looks at
> all the svc_versions for a particular
> svc_program, and returns "true" if any of them
> have vs_hidden unset? The mechanism you're
> proposing here has the potential to be out of
> sync with the vs_hidden flag.
>
Could you, please, clarify me this vs_hidden flag?
I understand, that it's used to avoid portmap registration.
But as I see, it's set only for nfs_callback_version1. But this svc_version is a
part of nfs4_callback_program with nfs_callback_version4, which is not hidden.
Does this flag is missed here? If not, how we can return "true" from your
proposed function if any of them have vs_hidden unset?
Also sockets for this program are created with SVC_SOCK_ANONYMOUS flag and we
will not register any of this program versions with portmapper.
Thus, from my pow, this vs_hidden flag affects only svc_unregister. And only
nfs_callback_version1. This looks really strange.
I.e. if we use this flag only for passing through this versions during
svc_(un)register, and we actually also want to pass through
nfs_callback_version4 as well (but just missed this vs_hidden flag for it), then
with current patch-set we can move this flag from (vs_hidden) svc_version to
svc_program and check it during svc_create instead of my home-brew
"setup_rpcbind" variable.
> Also, if you're adding an argument to a
> function like this, you you really ought to
> change the callers in the same patch. Otherwise
> you'll cause a build break if someone tries to
> bisect and ends up between the patch that
> changes the function and the one that changes
> the callers.
>
>> void (*shutdown)(struct svc_serv *));
>> struct svc_rqst *svc_prepare_thread(struct svc_serv *serv,
>> struct svc_pool *pool);
>> void svc_exit_thread(struct svc_rqst *);
>> struct svc_serv * svc_create_pooled(struct svc_program *, unsigned int,
>> + int setup_rpcbind,
>> void (*shutdown)(struct svc_serv *),
>> svc_thread_fn, struct module *);
>> int svc_set_num_threads(struct svc_serv *, struct svc_pool *, int);
>> diff --git a/net/sunrpc/svc.c b/net/sunrpc/svc.c
>> index f31e5cc..03231d5 100644
>> --- a/net/sunrpc/svc.c
>> +++ b/net/sunrpc/svc.c
>> @@ -378,7 +378,7 @@ static void svc_rpcb_cleanup(struct svc_serv *serv)
>> */
>> static struct svc_serv *
>> __svc_create(struct svc_program *prog, unsigned int bufsize, int npools,
>> - void (*shutdown)(struct svc_serv *serv))
>> + int setup_rpcbind, void (*shutdown)(struct svc_serv *serv))
>> {
>> struct svc_serv *serv;
>> unsigned int vers;
>> @@ -437,29 +437,36 @@ __svc_create(struct svc_program *prog, unsigned int bufsize, int npools,
>> spin_lock_init(&pool->sp_lock);
>> }
>>
>> - /* Remove any stale portmap registrations */
>> - svc_unregister(serv);
>> + if (setup_rpcbind) {
>> + if (svc_rpcb_setup(serv)< 0) {
>> + kfree(serv->sv_pools);
>> + kfree(serv);
>> + return NULL;
>> + }
>> + if (!serv->sv_shutdown)
>> + serv->sv_shutdown = svc_rpcb_cleanup;
>> + }
>>
>> return serv;
>> }
>>
>> struct svc_serv *
>> svc_create(struct svc_program *prog, unsigned int bufsize,
>> - void (*shutdown)(struct svc_serv *serv))
>> + int setup_rpcbind, void (*shutdown)(struct svc_serv *serv))
>> {
>> - return __svc_create(prog, bufsize, /*npools*/1, shutdown);
>> + return __svc_create(prog, bufsize, /*npools*/1, setup_rpcbind, shutdown);
>> }
>> EXPORT_SYMBOL_GPL(svc_create);
>>
>> struct svc_serv *
>> svc_create_pooled(struct svc_program *prog, unsigned int bufsize,
>> - void (*shutdown)(struct svc_serv *serv),
>> + int setup_rpcbind, void (*shutdown)(struct svc_serv *serv),
>> svc_thread_fn func, struct module *mod)
>> {
>> struct svc_serv *serv;
>> unsigned int npools = svc_pool_map_get();
>>
>> - serv = __svc_create(prog, bufsize, npools, shutdown);
>> + serv = __svc_create(prog, bufsize, npools, setup_rpcbind, shutdown);
>>
>> if (serv != NULL) {
>> serv->sv_function = func;
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
--
Best regards,
Stanislav Kinsbursky
^ permalink raw reply
* Re: [net-next RFC V2 PATCH 0/5] Multiqueue support in tun/tap
From: Ben Hutchings @ 2011-09-19 14:45 UTC (permalink / raw)
To: Jason Wang
Cc: krkumar2, eric.dumazet, mst, netdev, linux-kernel, virtualization,
davem, kvm, rusty, qemu-devel, mirq-linux, joe, shemminger
In-Reply-To: <20110917055639.32666.89940.stgit@dhcp-91-7.nay.redhat.com.englab.nay.redhat.com>
On Sat, 2011-09-17 at 14:02 +0800, Jason Wang wrote:
[...]
> 2 Current implementation may also get regression for single session
> packet transmission.
>
> The reason is packets from each flow were not handled by the same
> queue/vhost thread.
>
> Various method could be done to handle this:
>
> 2.1 hack the guest driver, and store the queue index into the rxhash and
> use it when choosing tx in guest. This need some hack to store the
> rxhash into sk and pass it in to skb again in
> skb_orphan_try(). sk_rxhash is only used by RPS now, so some more
> clean method is needed.
[...]
I have previously suggested doing this as a general rule. However, I
now think we can do much better with accelerated RFS and automatic XPS
(but the latter is not yet implemented). For virtio_net, accelerated
RFS would effectively push the guest's RFS socket map out to the host.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH v3 04/11] SUNRPC: parametrize svc creation calls with portmapper flag
From: Jeff Layton @ 2011-09-19 14:08 UTC (permalink / raw)
To: Stanislav Kinsbursky
Cc: Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA,
linux-nfs-u79uwXL29TY76Z2rM5mHXA, xemul-bzQdu9zFT3WakBO8gow8eQ,
neilb-l3A5Bk7waGM, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
bfields-uC3wQj2KruNg9hUCZPvPmw, davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <20110913181351.3961.70207.stgit-bi+AKbBUZKagILUCTcTcHdKyNwTtLsGr@public.gmane.org>
On Tue, 13 Sep 2011 22:13:51 +0400
Stanislav Kinsbursky <skinsbursky-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org> wrote:
> This new flag ("setup_rpcbind) will be used to detect, that new service will
> send portmapper register calls. For such services we will create rpcbind
> clients and remove all stale portmap registrations.
> Also, svc_rpcb_cleanup() will be set as sv_shutdown callback for such services
> in case of this field wasn't initialized earlier. This will allow to destroy
> rpcbind clients when no other users of them left.
>
> Signed-off-by: Stanislav Kinsbursky <skinsbursky-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
>
> ---
> include/linux/sunrpc/svc.h | 2 ++
> net/sunrpc/svc.c | 21 ++++++++++++++-------
> 2 files changed, 16 insertions(+), 7 deletions(-)
>
> diff --git a/include/linux/sunrpc/svc.h b/include/linux/sunrpc/svc.h
> index 223588a..528952a 100644
> --- a/include/linux/sunrpc/svc.h
> +++ b/include/linux/sunrpc/svc.h
> @@ -402,11 +402,13 @@ struct svc_procedure {
> * Function prototypes.
> */
> struct svc_serv *svc_create(struct svc_program *, unsigned int,
> + int setup_rpcbind,
^^^
Instead of adding this parameter, why not
base this on the vs_hidden flag in the
svc_version? IOW, have a function that looks at
all the svc_versions for a particular
svc_program, and returns "true" if any of them
have vs_hidden unset? The mechanism you're
proposing here has the potential to be out of
sync with the vs_hidden flag.
Also, if you're adding an argument to a
function like this, you you really ought to
change the callers in the same patch. Otherwise
you'll cause a build break if someone tries to
bisect and ends up between the patch that
changes the function and the one that changes
the callers.
> void (*shutdown)(struct svc_serv *));
> struct svc_rqst *svc_prepare_thread(struct svc_serv *serv,
> struct svc_pool *pool);
> void svc_exit_thread(struct svc_rqst *);
> struct svc_serv * svc_create_pooled(struct svc_program *, unsigned int,
> + int setup_rpcbind,
> void (*shutdown)(struct svc_serv *),
> svc_thread_fn, struct module *);
> int svc_set_num_threads(struct svc_serv *, struct svc_pool *, int);
> diff --git a/net/sunrpc/svc.c b/net/sunrpc/svc.c
> index f31e5cc..03231d5 100644
> --- a/net/sunrpc/svc.c
> +++ b/net/sunrpc/svc.c
> @@ -378,7 +378,7 @@ static void svc_rpcb_cleanup(struct svc_serv *serv)
> */
> static struct svc_serv *
> __svc_create(struct svc_program *prog, unsigned int bufsize, int npools,
> - void (*shutdown)(struct svc_serv *serv))
> + int setup_rpcbind, void (*shutdown)(struct svc_serv *serv))
> {
> struct svc_serv *serv;
> unsigned int vers;
> @@ -437,29 +437,36 @@ __svc_create(struct svc_program *prog, unsigned int bufsize, int npools,
> spin_lock_init(&pool->sp_lock);
> }
>
> - /* Remove any stale portmap registrations */
> - svc_unregister(serv);
> + if (setup_rpcbind) {
> + if (svc_rpcb_setup(serv) < 0) {
> + kfree(serv->sv_pools);
> + kfree(serv);
> + return NULL;
> + }
> + if (!serv->sv_shutdown)
> + serv->sv_shutdown = svc_rpcb_cleanup;
> + }
>
> return serv;
> }
>
> struct svc_serv *
> svc_create(struct svc_program *prog, unsigned int bufsize,
> - void (*shutdown)(struct svc_serv *serv))
> + int setup_rpcbind, void (*shutdown)(struct svc_serv *serv))
> {
> - return __svc_create(prog, bufsize, /*npools*/1, shutdown);
> + return __svc_create(prog, bufsize, /*npools*/1, setup_rpcbind, shutdown);
> }
> EXPORT_SYMBOL_GPL(svc_create);
>
> struct svc_serv *
> svc_create_pooled(struct svc_program *prog, unsigned int bufsize,
> - void (*shutdown)(struct svc_serv *serv),
> + int setup_rpcbind, void (*shutdown)(struct svc_serv *serv),
> svc_thread_fn func, struct module *mod)
> {
> struct svc_serv *serv;
> unsigned int npools = svc_pool_map_get();
>
> - serv = __svc_create(prog, bufsize, npools, shutdown);
> + serv = __svc_create(prog, bufsize, npools, setup_rpcbind, shutdown);
>
> if (serv != NULL) {
> serv->sv_function = func;
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH ] dynamic_debug: call __netdev_printk only for CONFIG_NET
From: Jason Baron @ 2011-09-19 13:48 UTC (permalink / raw)
To: Greg KH
Cc: Arnd Bergmann, gregkh, joe, jim.cromie, bvanassche, linux-kernel,
davem, aloisio.almeida, netdev, akpm, rdunlap
In-Reply-To: <20110918082736.GB19444@kroah.com>
On Sun, Sep 18, 2011 at 01:27:36AM -0700, Greg KH wrote:
> On Thu, Sep 01, 2011 at 11:18:18AM -0400, Jason Baron wrote:
> > On Thu, Sep 01, 2011 at 04:57:02PM +0200, Arnd Bergmann wrote:
> > > __netdev_printk is only defined when CONFIG_NET is set. Since we only need
> > > __dynamic_netdev_dbg for network drivers, we can make it conditional on the
> > > same Kconfig symbol.
> > >
> >
> > Hi,
> >
> > Yes, I've posted a fix for this:
> >
> > https://lkml.org/lkml/2011/8/30/297
> >
> > Hopefully, it will be pulled in soon.
>
> As that thread again spun off into confusion, can you please resend the
> end result?
>
> thanks,
>
> greg k-h
Hi,
Andrew Morton has pulled these into his -mm tree...so I think the series
should be all set.
Thanks,
-Jason
^ permalink raw reply
* Re: discrepancy in ip(7) wrt. IP DF flag for UDP sockets
From: Neil Horman @ 2011-09-19 13:03 UTC (permalink / raw)
To: Benjamin Poirier
Cc: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w,
linux-man-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20110919121940.GA19942-k/PPzeaMb74v2OKnPYDugg@public.gmane.org>
On Mon, Sep 19, 2011 at 08:19:40AM -0400, Benjamin Poirier wrote:
> Hi,
>
> I noticed what appears to be a discrepancy between the ip(7) man page
> and the kernel code with regards to the IP DF flag for UDP sockets.
>
> The man page says that "The don't-fragment flag is set on all outgoing
> datagrams" and that the ip_no_pmtu_disc sysctl affects only SOCK_STREAM
> sockets. This is quickly disproved by doing:
> echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc
> firing up netcat and looking at a few outgoing udp packets in wireshark
> (they don't have the DF flag set).
>
> 1) in the words of `man 7 ip`:
> IP_MTU_DISCOVER (since Linux 2.2)
> Set or receive the Path MTU Discovery setting for a socket.
> When enabled, Linux will perform Path MTU Discovery as defined
> in RFC 1191 on this socket. The don't-fragment flag is set on
> all outgoing datagrams. The system-wide default is controlled
> by the /proc/sys/net/ipv4/ip_no_pmtu_disc file for SOCK_STREAM
> sockets, and disabled on all others.
>
> This is the text present in the latest version of the online manpages,
> http://webcache.googleusercontent.com/search?q=cache:http://www.kernel.org/doc/man-pages/reporting_bugs.html&ie=UTF-8
>
> 2) in net/ipv4/af_inet.c:inet_create():
> if (ipv4_config.no_pmtu_disc)
> inet->pmtudisc = IP_PMTUDISC_DONT;
> else
> inet->pmtudisc = IP_PMTUDISC_WANT;
>
> and pmtudisc is left alone from there on for UDP sockets.
>
> What should be adjusted, the man page or the code?
>
The man page is wrong I think
By my read, the code:
1) Affects UDP and TCP the same way (which makes sense to me)
2) Is doing exactly what you asked it to, since you set no_pmtu_disc, which
means the stack should be free to fragment a frame as it sees fit according to
the MTU metric of the route its traversing, hence the cleared DF bit in the
fraem.
RFC 1191 can apply equally well to udp, as tcp, and is evident in that you can
set the per-socket option IP_MTU_DISCOVER to any of the 4 acceptible values
offered (DONT/WANT/DO/PROBE), so theres no reason the sysctl governing the
default value at creation shouldn't apply as well.
Neil
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Winning Notification Result*( You have won £750,000.00 )
From: Bmw Group @ 2011-09-19 12:22 UTC (permalink / raw)
Congratulation!!! your E-mail have won you the sum of Seven Hundred
Thousand Pounds British Pounds{£750,000.00} and bmw car to claim your
prize. Contact your Agent Mr Peter Wales via E-mail:
bmwgroupdept101@pwdh.net with the following informations.
Your Full Name:
Country:
Occupation:
Phone Number:
Address:
Best Regards,
Dr James Osho
DIRECTOR OF PROMOTIONS.
^ permalink raw reply
* Re: [BUG net-next] lost bnx2x
From: Eric Dumazet @ 2011-09-19 12:38 UTC (permalink / raw)
To: dmitry; +Cc: David Miller, netdev, Eilon Greenstein
In-Reply-To: <1316433920.2539.18.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
Le lundi 19 septembre 2011 à 14:05 +0200, Eric Dumazet a écrit :
> Le lundi 19 septembre 2011 à 14:54 +0300, Dmitry Kravkov a écrit :
> > On Sun, 2011-09-18 at 21:32 -0700, Eric Dumazet wrote:
> > > With latest net-next, my bnx2x doesnt start
> > >
> > > bnx2x: Can't load firmware file bnx2x/bnx2x-e1h-7.0.23.0.fw
> > >
> > > But I do have the file in /lib/firmware/bnx2x/bnx2x-e1h-7.0.23.0.fw
> > >
> >
> > Just pulled net-next - bnx2x device can load and pass traffic(on x86-64)
> > Can you provide more details about your setup?
>
> Please hold on, it might be because of my af_unix patches.
>
> I am investigating right now.
>
>
Yes, it appears that udevd relies on receiving CREDENTIAL in af_unix
messages.
Sorry for the false alarm, bnx2x works well once udevd is functional.
^ permalink raw reply
* discrepancy in ip(7) wrt. IP DF flag for UDP sockets
From: Benjamin Poirier @ 2011-09-19 12:19 UTC (permalink / raw)
To: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w,
linux-man-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
Hi,
I noticed what appears to be a discrepancy between the ip(7) man page
and the kernel code with regards to the IP DF flag for UDP sockets.
The man page says that "The don't-fragment flag is set on all outgoing
datagrams" and that the ip_no_pmtu_disc sysctl affects only SOCK_STREAM
sockets. This is quickly disproved by doing:
echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc
firing up netcat and looking at a few outgoing udp packets in wireshark
(they don't have the DF flag set).
1) in the words of `man 7 ip`:
IP_MTU_DISCOVER (since Linux 2.2)
Set or receive the Path MTU Discovery setting for a socket.
When enabled, Linux will perform Path MTU Discovery as defined
in RFC 1191 on this socket. The don't-fragment flag is set on
all outgoing datagrams. The system-wide default is controlled
by the /proc/sys/net/ipv4/ip_no_pmtu_disc file for SOCK_STREAM
sockets, and disabled on all others.
This is the text present in the latest version of the online manpages,
http://webcache.googleusercontent.com/search?q=cache:http://www.kernel.org/doc/man-pages/reporting_bugs.html&ie=UTF-8
2) in net/ipv4/af_inet.c:inet_create():
if (ipv4_config.no_pmtu_disc)
inet->pmtudisc = IP_PMTUDISC_DONT;
else
inet->pmtudisc = IP_PMTUDISC_WANT;
and pmtudisc is left alone from there on for UDP sockets.
What should be adjusted, the man page or the code?
Thanks,
-Ben
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [BUG net-next] lost bnx2x
From: Eric Dumazet @ 2011-09-19 12:05 UTC (permalink / raw)
To: dmitry; +Cc: David Miller, netdev, Eilon Greenstein
In-Reply-To: <1316433250.4154.3.camel@lb-tlvb-dmitry>
Le lundi 19 septembre 2011 à 14:54 +0300, Dmitry Kravkov a écrit :
> On Sun, 2011-09-18 at 21:32 -0700, Eric Dumazet wrote:
> > With latest net-next, my bnx2x doesnt start
> >
> > bnx2x: Can't load firmware file bnx2x/bnx2x-e1h-7.0.23.0.fw
> >
> > But I do have the file in /lib/firmware/bnx2x/bnx2x-e1h-7.0.23.0.fw
> >
>
> Just pulled net-next - bnx2x device can load and pass traffic(on x86-64)
> Can you provide more details about your setup?
Please hold on, it might be because of my af_unix patches.
I am investigating right now.
^ permalink raw reply
* Re: [BUG net-next] lost bnx2x
From: Dmitry Kravkov @ 2011-09-19 11:54 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, Eilon Greenstein
In-Reply-To: <1316406760.2521.18.camel@edumazet-laptop>
On Sun, 2011-09-18 at 21:32 -0700, Eric Dumazet wrote:
> With latest net-next, my bnx2x doesnt start
>
> bnx2x: Can't load firmware file bnx2x/bnx2x-e1h-7.0.23.0.fw
>
> But I do have the file in /lib/firmware/bnx2x/bnx2x-e1h-7.0.23.0.fw
>
Just pulled net-next - bnx2x device can load and pass traffic(on x86-64)
Can you provide more details about your setup?
^ permalink raw reply
* 群发软件+买家搜索机+109届广交会买家、海关数据,B2B询盘买家500万。
From: 仅10元每天 @ 2011-09-19 11:15 UTC (permalink / raw)
To: net.inox, net, net, net6688yes, netavemshink, netc75, netdev,
netflagking
群发软件+109届广交会买家、海关数据、搜索引擎买家,B2B询盘买家共500万,仅10元每天。
保证每天都有买家回复。
保证每天都有买家回复。
1、群发软件： 操作简单，功能强大，模仿人工操作模式，到达率高，日发送5万封以上。
2、500万广交会买家资源： 赠送的500万买家资源库，每月更新 。
3、超级海外买家Email搜索机： 每天能搜索1-2万以上买家真实EMAIL，成单率高。
要的抓紧联系QQ: 1339625218 或者立即回复邮箱: 1339625218@qq.com
要的抓紧联系QQ: 1339625218 或者立即回复邮箱: 1339625218@qq.com
要的抓紧联系QQ: 1339625218 或者立即回复邮箱: 1339625218@qq.com
免费赠送:
一共8个包(数据是全行业的，按照行业分好类，并且可以按照关键词查询的)：
1，2011春季109届广交会买家现场询盘数据库新鲜出炉，超级新鲜买家，新鲜数据，容易成单！
2，购买后可以免费更新2011秋季广交会+2012春季广交会买家数据。太超值了。
3，最新全球买家库,共451660条数据。 (最新更新日期 2011-05-16日)
4，2008年,2009年,2010年 春季+秋季广交会买家名录，103 104 105 106 107 108 共六届 共120.6万数据。
5，2010年国际促销协会（PPAI）成员名单 PPAI Members Directory，非常重要的大买家。
6，2010年到香港采购的国外客人名录(香港贸发局提供)，共7.2万数据，超级重要的买家。
7，48.68万条最新买家询盘，购买后每月更新 1-2万条，包括2部分，1，最新的询盘 2，最新的展会买家。免费更新36个月。
8，2009年海关提单数据piers版数据 1千万。
诚信为本，支持支付宝担保交易 (先发货并安装设置群发软件，然后付款) 彻底打消您的 顾虑。
精准数据-成单率极高
精准数据-成单率极高
精准数据-成单率极高
精准数据-成单率极高
精准数据-成单率极高
^ permalink raw reply
* Re: [GIT] Networking
From: Neil Horman @ 2011-09-19 11:02 UTC (permalink / raw)
To: David Ward; +Cc: Linus Torvalds, David Miller, akpm, netdev, linux-kernel
In-Reply-To: <4E76864D.4080907@ll.mit.edu>
On Sun, Sep 18, 2011 at 08:01:17PM -0400, David Ward wrote:
> On 09/18/2011 02:06 PM, Linus Torvalds wrote:
> >2011/9/17 David Miller<davem@davemloft.net>:
> >>dpward (2):
> >> net: Make flow cache namespace-aware
> >> net: Handle different key sizes between address families in flow cache
> >>
> >>nhorman (1):
> >> net: don't clear IFF_XMIT_DST_RELEASE in ether_setup
> >>
> >>rajan.aggarwal85@gmail.com (1):
> >> net/can/af_can.c: Change del_timer to del_timer_sync
> >Guys, if somebody has such a broken email setup that they don't even
> >show their own name, don't take patches from them.
>
> At least in my case, that is Patchwork's fault. My name only
> started showing up like that in commits after I registered for an
> account (http://patchwork.ozlabs.org/register/), and I don't see any
> way to change the way my name appears in the Patchwork profile
> options.
>
> The emails I sent to the netdev list showed my full name; see:
> http://marc.info/?l=linux-netdev&m=131527867326729&w=2
> http://marc.info/?l=linux-netdev&m=131527879226819&w=2
>
I noticed this the other day when I registered as well. Not sure what patchwork
is doing.
Neil
> David
>
^ permalink raw reply
* RE: PATCH Question, Firewall mark inherit for ip6_tunnel
From: Eric Dumazet @ 2011-09-19 10:32 UTC (permalink / raw)
To: Hans Schillström; +Cc: netdev@vger.kernel.org
In-Reply-To: <C8A6796DE7C66C4ABCBC18106CB6C1CC106D90310A@ESESSCMS0356.eemea.ericsson.se>
Le lundi 19 septembre 2011 à 11:52 +0200, Hans Schillström a écrit :
> Thanks Eric,
> Do you take care of the user mode part as well (i.ie ip commad)
Yes, I'll send the iproute2 part as well.
^ permalink raw reply
* RE: PATCH Question, Firewall mark inherit for ip6_tunnel
From: Hans Schillström @ 2011-09-19 9:52 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev@vger.kernel.org
In-Reply-To: <1316424324.2539.6.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
>From: Eric Dumazet [eric.dumazet@gmail.com]
>Sent: Monday, September 19, 2011 11:25
>To: Hans Schillström
>Cc: netdev@vger.kernel.org
>Subject: Re: PATCH Question, Firewall mark inherit for ip6_tunnel
>
>Le lundi 19 septembre 2011 à 10:47 +0200, Hans Schillström a écrit :
>> Hello Eric,
>> For a year ago you send an untested patch to Anders Franzen
>> I think the subject was "not possible to do policy routing for next hop on tunnels."
>>
>> The patch have been used since that and it works perfectly,
>> I made some minor changes to reflect the flowi changes.
>>
>> Would it be possible for you to submit that patch, since (I guess) you are the author
>> I can prepare it if you want.
>> The included patch is for linux-3.0.4
>>
>> Regards
>> Hans Schillstrom
>
>Hello Hans
>
>Yes, I'll respin this patch on top on net-next, with your "Tested-by"
>signature ;)
>
>Thanks
Thanks Eric,
Do you take care of the user mode part as well (i.ie ip commad)
Hans
^ permalink raw reply
* Re: [PATCH] macvtap: fix the uninitialized var using in macvtap_alloc_skb()
From: Michael S. Tsirkin @ 2011-09-19 9:54 UTC (permalink / raw)
To: Jason Wang; +Cc: netdev, davem, linux-kernel
In-Reply-To: <20110919094830.6272.40503.stgit@dhcp-91-7.nay.redhat.com.englab.nay.redhat.com>
On Mon, Sep 19, 2011 at 05:48:31PM +0800, Jason Wang wrote:
> Commit d1b08284 use new frag API but would leave f to be used
> uninitialized, this patch fix it.
>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Good catch. Makes absolute sense.
Acked-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> drivers/net/macvtap.c | 12 +++++-------
> 1 files changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
> index 7c3f84a..3da5578 100644
> --- a/drivers/net/macvtap.c
> +++ b/drivers/net/macvtap.c
> @@ -453,7 +453,6 @@ static int zerocopy_sg_from_iovec(struct sk_buff *skb, const struct iovec *from,
> int copy = skb_headlen(skb);
> int size, offset1 = 0;
> int i = 0;
> - skb_frag_t *f;
>
> /* Skip over from offset */
> while (count && (offset >= from->iov_len)) {
> @@ -503,14 +502,13 @@ static int zerocopy_sg_from_iovec(struct sk_buff *skb, const struct iovec *from,
> skb->truesize += len;
> atomic_add(len, &skb->sk->sk_wmem_alloc);
> while (len) {
> - __skb_fill_page_desc(
> - skb, i, page[i],
> - base & ~PAGE_MASK,
> - min_t(int, len, PAGE_SIZE - f->page_offset));
> + int off = base & ~PAGE_MASK;
> + int size = min_t(int, len, PAGE_SIZE - off);
> + __skb_fill_page_desc(skb, i, page[i], off, size);
> skb_shinfo(skb)->nr_frags++;
> /* increase sk_wmem_alloc */
> - base += f->size;
> - len -= f->size;
> + base += size;
> + len -= size;
> i++;
> }
> offset1 = 0;
^ permalink raw reply
* [PATCH] macvtap: fix the uninitialized var using in macvtap_alloc_skb()
From: Jason Wang @ 2011-09-19 9:48 UTC (permalink / raw)
To: netdev, mst, davem, linux-kernel
Commit d1b08284 use new frag API but would leave f to be used
uninitialized, this patch fix it.
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/net/macvtap.c | 12 +++++-------
1 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index 7c3f84a..3da5578 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -453,7 +453,6 @@ static int zerocopy_sg_from_iovec(struct sk_buff *skb, const struct iovec *from,
int copy = skb_headlen(skb);
int size, offset1 = 0;
int i = 0;
- skb_frag_t *f;
/* Skip over from offset */
while (count && (offset >= from->iov_len)) {
@@ -503,14 +502,13 @@ static int zerocopy_sg_from_iovec(struct sk_buff *skb, const struct iovec *from,
skb->truesize += len;
atomic_add(len, &skb->sk->sk_wmem_alloc);
while (len) {
- __skb_fill_page_desc(
- skb, i, page[i],
- base & ~PAGE_MASK,
- min_t(int, len, PAGE_SIZE - f->page_offset));
+ int off = base & ~PAGE_MASK;
+ int size = min_t(int, len, PAGE_SIZE - off);
+ __skb_fill_page_desc(skb, i, page[i], off, size);
skb_shinfo(skb)->nr_frags++;
/* increase sk_wmem_alloc */
- base += f->size;
- len -= f->size;
+ base += size;
+ len -= size;
i++;
}
offset1 = 0;
^ permalink raw reply related
* Re: [net-next RFC V2 PATCH 0/5] Multiqueue support in tun/tap
From: Jason Wang @ 2011-09-19 9:44 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: krkumar2, kvm, eric.dumazet, qemu-devel, netdev, rusty,
linux-kernel, virtualization, joe, shemminger, mirq-linux, davem
In-Reply-To: <20110917191709.GA6127@redhat.com>
On 09/18/2011 03:17 AM, Michael S. Tsirkin wrote:
> On Sat, Sep 17, 2011 at 02:02:04PM +0800, Jason Wang wrote:
>> A wiki-page was created to narrate the detail design of all parts
>> involved in the multi queue implementation:
>> http://www.linux-kvm.org/page/Multiqueue and some basic tests result
>> could be seen in this page
>> http://www.linux-kvm.org/page/Multiqueue-performance-Sep-13. I would
>> post the detail numbers in attachment as the reply of this thread.
> Does it make sense to test both with and without RPS in guest?
>
I've tested with RPS in guest, but didn't see improvements.
^ permalink raw reply
* Re: PATCH Question, Firewall mark inherit for ip6_tunnel
From: Eric Dumazet @ 2011-09-19 9:25 UTC (permalink / raw)
To: Hans Schillström; +Cc: netdev@vger.kernel.org
In-Reply-To: <C8A6796DE7C66C4ABCBC18106CB6C1CC106D903109@ESESSCMS0356.eemea.ericsson.se>
Le lundi 19 septembre 2011 à 10:47 +0200, Hans Schillström a écrit :
> Hello Eric,
> For a year ago you send an untested patch to Anders Franzen
> I think the subject was "not possible to do policy routing for next hop on tunnels."
>
> The patch have been used since that and it works perfectly,
> I made some minor changes to reflect the flowi changes.
>
> Would it be possible for you to submit that patch, since (I guess) you are the author
> I can prepare it if you want.
> The included patch is for linux-3.0.4
>
> Regards
> Hans Schillstrom
Hello Hans
Yes, I'll respin this patch on top on net-next, with your "Tested-by"
signature ;)
Thanks
^ permalink raw reply
* PATCH Question, Firewall mark inherit for ip6_tunnel
From: Hans Schillström @ 2011-09-19 8:47 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev@vger.kernel.org
Hello Eric,
For a year ago you send an untested patch to Anders Franzen
I think the subject was "not possible to do policy routing for next hop on tunnels."
The patch have been used since that and it works perfectly,
I made some minor changes to reflect the flowi changes.
Would it be possible for you to submit that patch, since (I guess) you are the author
I can prepare it if you want.
The included patch is for linux-3.0.4
Regards
Hans Schillstrom
diff --git a/include/linux/ip6_tunnel.h b/include/linux/ip6_tunnel.h
index acb9ad6..bf22b03 100644
--- a/include/linux/ip6_tunnel.h
+++ b/include/linux/ip6_tunnel.h
@@ -16,6 +16,8 @@
#define IP6_TNL_F_MIP6_DEV 0x8
/* copy DSCP from the outer packet */
#define IP6_TNL_F_RCV_DSCP_COPY 0x10
+/* copy fwmark from inner packet */
+#define IP6_TNL_F_USE_ORIG_FWMARK 0x20
struct ip6_tnl_parm {
char name[IFNAMSIZ]; /* name of tunnel device */
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index 36c2842..64be21c 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -897,7 +897,7 @@ static int ip6_tnl_xmit2(struct sk_buff *skb,
int err = -1;
int pkt_len;
- if ((dst = ip6_tnl_dst_check(t)) != NULL)
+ if (!fl6->flowi6_mark && (dst = ip6_tnl_dst_check(t)) != NULL)
dst_hold(dst);
else {
dst = ip6_route_output(net, NULL, fl6);
@@ -955,7 +955,7 @@ static int ip6_tnl_xmit2(struct sk_buff *skb,
skb = new_skb;
}
skb_dst_drop(skb);
- skb_dst_set(skb, dst_clone(dst));
+ skb_dst_set(skb, fl6->flowi6_mark ? dst : dst_clone(dst));
skb->transport_header = skb->network_header;
@@ -987,7 +987,9 @@ static int ip6_tnl_xmit2(struct sk_buff *skb,
stats->tx_errors++;
stats->tx_aborted_errors++;
}
- ip6_tnl_dst_store(t, dst);
+ if (!fl6->flowi6_mark)
+ ip6_tnl_dst_store(t, dst);
+
return 0;
tx_err_link_failure:
stats->tx_carrier_errors++;
@@ -1023,6 +1025,8 @@ ip4ip6_tnl_xmit(struct sk_buff *skb, struct net_device *dev)
if ((t->parms.flags & IP6_TNL_F_USE_ORIG_TCLASS))
fl6.flowlabel |= htonl((__u32)iph->tos << IPV6_TCLASS_SHIFT)
& IPV6_TCLASS_MASK;
+ if ((t->parms.flags & IP6_TNL_F_USE_ORIG_FWMARK))
+ fl6.flowi6_mark = skb->mark;
err = ip6_tnl_xmit2(skb, dev, dsfield, &fl6, encap_limit, &mtu);
if (err != 0) {
@@ -1073,7 +1077,8 @@ ip6ip6_tnl_xmit(struct sk_buff *skb, struct net_device *dev)
fl6.flowlabel |= (*(__be32 *) ipv6h & IPV6_TCLASS_MASK);
if ((t->parms.flags & IP6_TNL_F_USE_ORIG_FLOWLABEL))
fl6.flowlabel |= (*(__be32 *) ipv6h & IPV6_FLOWLABEL_MASK);
-
+ if ((t->parms.flags & IP6_TNL_F_USE_ORIG_FWMARK))
+ fl6.flowi6_mark = skb->mark;
err = ip6_tnl_xmit2(skb, dev, dsfield, &fl6, encap_limit, &mtu);
if (err != 0) {
if (err == -EMSGSIZE)
--
1.7.4.4
^ permalink raw reply related
* Re: [PATCH 4/4] net/fec: add imx6q enet support
From: Shawn Guo @ 2011-09-19 9:08 UTC (permalink / raw)
To: Francois Romieu
Cc: Shawn Guo, netdev, David S. Miller, linux-arm-kernel, patches
In-Reply-To: <20110918180912.GA3734@electric-eye.fr.zoreil.com>
On Sun, Sep 18, 2011 at 08:09:12PM +0200, Francois Romieu wrote:
> Shawn Guo <shawn.guo@linaro.org> :
> [...]
> > diff --git a/drivers/net/fec.c b/drivers/net/fec.c
> > index 04206e4..849cb0b 100644
> > --- a/drivers/net/fec.c
> > +++ b/drivers/net/fec.c
> > @@ -442,18 +453,23 @@ fec_restart(struct net_device *ndev, int duplex)
> > /* Enable flow control and length check */
> > rcntl |= 0x40000000 | 0x00000020;
> >
> > - /* MII or RMII */
> > + /* RGMII, RMII or MII */
> > + if (fep->phy_interface == PHY_INTERFACE_MODE_RGMII)
> > + rcntl |= (1 << 6);
> > if (fep->phy_interface == PHY_INTERFACE_MODE_RMII)
> ^^^^ missing "else"
>
Yes, my bad.
> [...]
> > + /* 1G, 100M or 10M */
> > + if (fep->phy_dev) {
> > + if (fep->phy_dev->speed == SPEED_1000)
> > + ecntl |= (1 << 8);
Right, this is a typo. It should be (1 << 5);
> > + else if (fep->phy_dev->speed == SPEED_100)
> > + rcntl &= ~(1 << 9);
> > + else
> > + rcntl |= (1 << 9);
> > + }
> [...]
> > + if (id_entry->driver_data & FEC_QUIRK_ENET_MAC) {
> > + /* enable ENET endian swap */
> > + ecntl |= (1 << 8);
>
> I do not understand why the endian swap bit of ecntl needs to be
> set the same in these two different paths, especially as the latter
> handles the old faulty imx28 and the former the newly fixed imx6q.
> Typo ?
>
Nice catches. Thanks a lot, Ueimor.
--
Regards,
Shawn
^ permalink raw reply
* linux-next: build failure after merge of the final tree (origin/net-current tree related)
From: Stephen Rothwell @ 2011-09-19 8:35 UTC (permalink / raw)
To: David Miller, netdev; +Cc: linux-next, linux-kernel, Eric Dumazet
[-- Attachment #1: Type: text/plain, Size: 465 bytes --]
Hi all,
After merging the final tree, today's linux-next build (powerpc
ppc44x_defconfig) failed like this:
net/built-in.o: In function `tcp_v4_conn_request':
(.text+0x5b700): undefined reference to `cookie_v4_init_sequence'
This error has already been noted elsewhere and a fix queued, so I have
merged a newer version of the net-current tree that contains the fix for
today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH 1/1] snmp6 relevant data structures are freed twice.
From: Rongqing Li @ 2011-09-19 8:32 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1316420989.2539.5.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On 09/19/2011 04:29 PM, Eric Dumazet wrote:
> Le lundi 19 septembre 2011 à 15:03 +0800, rongqing.li@windriver.com a
> écrit :
>> From: Roy.Li<rongqing.li@windriver.com>
>>
>> When calling snmp6_alloc_dev fails, the snmp6 relevant memory
>> are freed by snmp6_alloc_dev. Calling in6_dev_finish_destroy
>> will free these memory twice.
>>
>> Double free will lead that undefined behavior occurs.
>>
>> Signed-off-by: Roy.Li<rongqing.li@windriver.com>
>> ---
>> net/ipv6/addrconf.c | 4 ++--
>> 1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
>> index 8f1e5be..ba01f72 100644
>> --- a/net/ipv6/addrconf.c
>> +++ b/net/ipv6/addrconf.c
>> @@ -374,8 +374,8 @@ static struct inet6_dev * ipv6_add_dev(struct net_device *dev)
>> "%s(): cannot allocate memory for statistics; dev=%s.\n",
>> __func__, dev->name));
>> neigh_parms_release(&nd_tbl, ndev->nd_parms);
>> - ndev->dead = 1;
>> - in6_dev_finish_destroy(ndev);
>> + dev_put(dev);
>> + kfree(ndev);
>> return NULL;
>> }
>>
>
> This seems a very old bug, and your fix applicable to old kernels as
> well, thanks.
>
> Could your patch title could be refined to the following ?
>
> 0) No need for the 1/1 suffix
> 1) include ipv6: prefix
> 2) change the message a bit, since normal operations are OK, only
> failure and error recovery is buggy.
>
> [PATCH] ipv6: fix a possible double free
>
> Acked-by: Eric Dumazet<eric.dumazet@gmail.com>
>
>
>
Ok, I will resend it.
--
Best Reagrds,
Roy | RongQing Li
^ permalink raw reply
* Re: [PATCH 1/1] snmp6 relevant data structures are freed twice.
From: Eric Dumazet @ 2011-09-19 8:29 UTC (permalink / raw)
To: rongqing.li; +Cc: netdev
In-Reply-To: <1316415793-2711-1-git-send-email-rongqing.li@windriver.com>
Le lundi 19 septembre 2011 à 15:03 +0800, rongqing.li@windriver.com a
écrit :
> From: Roy.Li <rongqing.li@windriver.com>
>
> When calling snmp6_alloc_dev fails, the snmp6 relevant memory
> are freed by snmp6_alloc_dev. Calling in6_dev_finish_destroy
> will free these memory twice.
>
> Double free will lead that undefined behavior occurs.
>
> Signed-off-by: Roy.Li <rongqing.li@windriver.com>
> ---
> net/ipv6/addrconf.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> index 8f1e5be..ba01f72 100644
> --- a/net/ipv6/addrconf.c
> +++ b/net/ipv6/addrconf.c
> @@ -374,8 +374,8 @@ static struct inet6_dev * ipv6_add_dev(struct net_device *dev)
> "%s(): cannot allocate memory for statistics; dev=%s.\n",
> __func__, dev->name));
> neigh_parms_release(&nd_tbl, ndev->nd_parms);
> - ndev->dead = 1;
> - in6_dev_finish_destroy(ndev);
> + dev_put(dev);
> + kfree(ndev);
> return NULL;
> }
>
This seems a very old bug, and your fix applicable to old kernels as
well, thanks.
Could your patch title could be refined to the following ?
0) No need for the 1/1 suffix
1) include ipv6: prefix
2) change the message a bit, since normal operations are OK, only
failure and error recovery is buggy.
[PATCH] ipv6: fix a possible double free
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
^ permalink raw reply
* Re: [PATCH -next v2] unix stream: Fix use-after-free crashes
From: Eric Dumazet @ 2011-09-19 7:57 UTC (permalink / raw)
To: Tim Chen
Cc: David Miller, zheng.z.yan, zheng.z.yan, netdev, sfr, jirislaby,
sedat.dilek, alex.shi
In-Reply-To: <1316191845.2201.5.camel@schen9-mobl>
Le vendredi 16 septembre 2011 à 09:50 -0700, Tim Chen a écrit :
> On Fri, 2011-09-16 at 19:35 -0400, David Miller wrote:
> > From: Eric Dumazet <eric.dumazet@gmail.com>
> > Date: Wed, 07 Sep 2011 04:55:26 +0200
> >
> > > Please David just revert 0856a304091b33a8e
> >
> > Done.
>
> Eric,
>
> Can you re-spin a patch that incorporates your idea that we don't
> add pid/credential references when we are not requesting credentials
> in the socket. And probably another one that remove unnecessary
> pid/credentials references in send/receive when we do use credentials?
Sure, I did it this morning, please review it if you have some time.
If we find a regression (some popular app doing write() and expecting
credential to be sent to receiver), we could test the SOCK_PASSCRED flag
on receiver socket.
^ permalink raw reply
* Re: [PATCH] virtio-net: Read MAC only after initializing MSI-X
From: Rusty Russell @ 2011-09-19 7:49 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Sasha Levin, linux-kernel, virtualization, netdev, kvm
In-Reply-To: <20110919060150.GB1569@redhat.com>
On Mon, 19 Sep 2011 09:01:50 +0300, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Mon, Sep 19, 2011 at 01:05:17PM +0930, Rusty Russell wrote:
> > On Sat, 20 Aug 2011 23:00:44 +0300, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > > On Fri, Aug 19, 2011 at 07:33:07PM +0300, Sasha Levin wrote:
> > > > Maybe this is better solved by copying the way it was done in PCI itself
> > > > with capability linked list?
> > >
> > > There are any number of ways to lay out the structure. I went for what
> > > seemed a simplest one. For MSI-X the train has left the station. We
> > > can probably still tweak where the high 32 bit features
> > > for 64 bit features are. No idea if it's worth it.
> >
> > Sorry, this has been in the back of my mind. I think it's a good idea;
> > can we use the capability linked list for pre-device specific stuff from
> > now on?
> >
> > Thanks,
> > Rusty.
>
> Do we even want capability bits then?
> We can give each capability an ack flag ...
We could have, and if I'd known PCI when I designed virtio I might have.
But it's not easy now to map structure offsets to that scheme, and we
can't really force such a change on the non-PCI users. So I'd say we
should only do it for the non-device-specific options. ie. we'll still
have the MSI-X case move the device-specific config, but we'll use a
linked list from now on, eg. for the next 32 features bits...
Thoughts?
Rusty.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox