[PATCH 1/1] staging: hv: remove netvsc send buffer and related functions
netvsc send buffer is not used, so remove it.
Signed-off-by: Haiyang Zhang
Signed-off-by: Hank Janssen
Signed-off-by: K. Y. Srinivasan
---
drivers/staging/hv/hyperv_net.h | 10 ---
drivers/staging/hv/netvsc.c | 161 ---
2 files changed, 0 insertions(+), 171 deletions(-)
diff --git a/drivers/staging/hv/hyperv_net.h b/drivers/staging/hv/hyperv_net.h
index cf762bd..27f987b 100644
--- a/drivers/staging/hv/hyperv_net.h
+++ b/drivers/staging/hv/hyperv_net.h
@@ -355,10 +355,6 @@ struct nvsp_message {
/* #define NVSC_MIN_PROTOCOL_VERSION 1 */
/* #define NVSC_MAX_PROTOCOL_VERSION 1 */
-#define NETVSC_SEND_BUFFER_SIZE(64*1024) /* 64K
*/
-#define NETVSC_SEND_BUFFER_ID 0xface
-
-
#define NETVSC_RECEIVE_BUFFER_SIZE (1024*1024) /* 1MB */
#define NETVSC_RECEIVE_BUFFER_ID 0xcafe
@@ -383,12 +379,6 @@ struct netvsc_device {
struct list_head recv_pkt_list;
spinlock_t recv_pkt_list_lock;
- /* Send buffer allocated by us but manages by NetVSP */
- void *send_buf;
- u32 send_buf_size;
- u32 send_buf_gpadl_handle;
- u32 send_section_size;
-
/* Receive buffer allocated by us but manages by NetVSP */
void *recv_buf;
u32 recv_buf_size;
diff --git a/drivers/staging/hv/netvsc.c b/drivers/staging/hv/netvsc.c
index 41cbb26..7b5bf0d 100644
--- a/drivers/staging/hv/netvsc.c
+++ b/drivers/staging/hv/netvsc.c
@@ -323,162 +323,6 @@ exit:
return ret;
}
-static int netvsc_destroy_send_buf(struct netvsc_device *net_device)
-{
- struct nvsp_message *revoke_packet;
- int ret = 0;
-
- /*
-* If we got a section count, it means we received a
-* SendReceiveBufferComplete msg (ie sent
-* NvspMessage1TypeSendReceiveBuffer msg) therefore, we need
-* to send a revoke msg here
-*/
- if (net_device->send_section_size) {
- /* Send the revoke send buffer */
- revoke_packet = &net_device->revoke_packet;
- memset(revoke_packet, 0, sizeof(struct nvsp_message));
-
- revoke_packet->hdr.msg_type =
- NVSP_MSG1_TYPE_REVOKE_SEND_BUF;
- revoke_packet->msg.v1_msg.
- revoke_send_buf.id = NETVSC_SEND_BUFFER_ID;
-
- ret = vmbus_sendpacket(net_device->dev->channel,
- revoke_packet,
- sizeof(struct nvsp_message),
- (unsigned long)revoke_packet,
- VM_PKT_DATA_INBAND, 0);
- /*
-* If we failed here, we might as well return and have a leak
-* rather than continue and a bugchk
-*/
- if (ret != 0) {
- dev_err(&net_device->dev->device, "unable to send "
- "revoke send buffer to netvsp");
- return -1;
- }
- }
-
- /* Teardown the gpadl on the vsp end */
- if (net_device->send_buf_gpadl_handle) {
- ret = vmbus_teardown_gpadl(net_device->dev->channel,
- net_device->send_buf_gpadl_handle);
-
- /*
-* If we failed here, we might as well return and have a leak
-* rather than continue and a bugchk
-*/
- if (ret != 0) {
- dev_err(&net_device->dev->device,
- "unable to teardown send buffer's gpadl");
- return -1;
- }
- net_device->send_buf_gpadl_handle = 0;
- }
-
- if (net_device->send_buf) {
- /* Free up the receive buffer */
- free_pages((unsigned long)net_device->send_buf,
- get_order(net_device->send_buf_size));
- net_device->send_buf = NULL;
- }
-
- return ret;
-}
-
-static int netvsc_init_send_buf(struct hv_device *device)
-{
- int ret = 0;
- int t;
- struct netvsc_device *net_device;
- struct nvsp_message *init_packet;
-
- net_device = get_outbound_net_device(device);
- if (!net_device) {
- dev_err(&device->device, "unable to get net device..."
- "device being destroyed?");
- return -1;
- }
- if (net_device->send_buf_size <= 0) {
- ret = -EINVAL;
- goto cleanup;
- }
-
- net_device->send_buf =
- (void *)__get_free_pages(GFP_KERNEL|__GFP_ZERO,
- get_order(net_device->send_buf_size));
- if (!net_device->send_buf) {
- dev_err(&device->device, "unable to allocate send "
- "buffer of size %d", n
Re: [PATCH] arch/tile: add /proc/tile, /proc/sys/tile, and a sysfs cpu attribute
On Wednesday 25 May 2011 22:31:37 Chris Metcalf wrote: > On 5/25/2011 4:20 PM, Arnd Bergmann wrote: > > On Wednesday 25 May 2011 21:18:05 Chris Metcalf wrote: > >> The contents of the hardwall ID file are then just a cpulist of the cpus > >> covered by the hardwall, rather than introducing a new convention (as > >> quoted above, e.g. "2x2 1,1"). Individual tasks that are in the hardwall > >> can be found by reading the "hardwall" files, and we can learn where they > >> are bound in the hardwall by reading the "stat" file as is normal for > >> learning process affinity. > > Be careful with listing PID values in the hardwall files, as the PIDs > > may not be unique or visible if you combine this with PID name spaces. > > I guess the right solution would be to only list the tasks that are > > present in the name space of the thread reading the file. > > Sorry not to be clearer -- I am no longer listing any PID values in the > hardwall files, for that exact reason. You have to look at > /proc/*/hardwall (or /proc/*/tasks/*/hardwall) to find the files that are > in a particular hardwall. This pattern is not one that's normally directly > useful, though, so I'm happy leaving it to userspace if it's desired. Ok, thanks for the clarification. Arnd ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [PATCH] arch/tile: add /proc/tile, /proc/sys/tile, and a sysfs cpu attribute
On 5/25/2011 4:20 PM, Arnd Bergmann wrote: > On Wednesday 25 May 2011 21:18:05 Chris Metcalf wrote: >> The contents of the hardwall ID file are then just a cpulist of the cpus >> covered by the hardwall, rather than introducing a new convention (as >> quoted above, e.g. "2x2 1,1"). Individual tasks that are in the hardwall >> can be found by reading the "hardwall" files, and we can learn where they >> are bound in the hardwall by reading the "stat" file as is normal for >> learning process affinity. > Be careful with listing PID values in the hardwall files, as the PIDs > may not be unique or visible if you combine this with PID name spaces. > I guess the right solution would be to only list the tasks that are > present in the name space of the thread reading the file. Sorry not to be clearer -- I am no longer listing any PID values in the hardwall files, for that exact reason. You have to look at /proc/*/hardwall (or /proc/*/tasks/*/hardwall) to find the files that are in a particular hardwall. This pattern is not one that's normally directly useful, though, so I'm happy leaving it to userspace if it's desired. >>> When you do a /sys/hypervisor/ interface, put everything into a subdirectory >>> under /sys/hypervisor with the name of your hypervisor, to avoid naming >>> conflicts, e.g. >>> >>> /sys/hypervisor/tilera-hv/board/board_serial > I just checked for other users. The only one I could find was > drivers/xen/sys-hypervisor.c, and it also doesn't use a subdirectory to > identify that hypervisor. It's probably more consistent if you also don't > do it then. > > You can create a directory with multiple files using sysfs_create_group() > as the xen code does, but not nested directories. I'll look into sysfs_create_group(), and then send a revised patch with all the /proc and /sys changes. Thanks! -- Chris Metcalf, Tilera Corp. http://www.tilera.com ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [PATCH] arch/tile: add /proc/tile, /proc/sys/tile, and a sysfs cpu attribute
On Wednesday 25 May 2011 21:18:05 Chris Metcalf wrote: > (Resending with no HTML for LKML.) > > On 5/20/2011 3:59 PM, Arnd Bergmann wrote: > > Any chance you can still restructure the information? I would recommend > > making it a first-class procfs member, since the data is really per-task. > > > > You can add a conditional entry to tgid_base_stuff[] in fs/proc/base.c > > to make it show up for each pid, and then just have the per-task information > > in there to do the lookup the other way round: > > > > # cat /proc/484/hardwall > > 2x2 1,1 @2,1 > > > > # cat /proc/479/hardwall > > 2x2 1,1 @1,1 > > Another problem with the existing interface is that it doesn't currently > > support PID name spaces. That could of course be retrofitted, but having > > the data split by pid directory would make it work implicitly. > > > > Another approach would be to have a /proc/hardwall/ directory with > > one entry per hardwall instance, and symlinks from /proc//hardwall > > to the respective file. > > I went ahead and implemented this, and will send out a v2 patch shortly. I > added the "hardwall" entry to both the tgid_base (since everything is > reflected there) but also to the tid_base_stuff[], since it can be > different (in principle) for different threads. Ok, sounds good. > I played around with using a symlink, but the bottom line seems to be that > if I make it a symlink (via a SYM() macro in the table) it always has to > exist -- so what does it point to when there's no hardwall activated? I > tried making it point to /dev/null, but that just seemed silly. In the end > I made /proc/PID/hardwall a file, either empty, or else containing the > hardwall id. ok. I suppose you could make a non-hardwall file that you can link to, but an empty file also sounds ok. > The actual hardwalls are then in /proc/tile/hardwall/NN, where NN is the > hardwall id. I wrote a very simple hardwall id allocate/free pair; the pid > allocator seemed too tied to task_structs. We only need at most NR_CPUS > hardwall ids, so it's pretty simple to just use a cpumask to hold the set > of allocated hardwall IDs. ok. > The contents of the hardwall ID file are then just a cpulist of the cpus > covered by the hardwall, rather than introducing a new convention (as > quoted above, e.g. "2x2 1,1"). Individual tasks that are in the hardwall > can be found by reading the "hardwall" files, and we can learn where they > are bound in the hardwall by reading the "stat" file as is normal for > learning process affinity. Be careful with listing PID values in the hardwall files, as the PIDs may not be unique or visible if you combine this with PID name spaces. I guess the right solution would be to only list the tasks that are present in the name space of the thread reading the file. > > When you do a /sys/hypervisor/ interface, put everything into a subdirectory > > under /sys/hypervisor with the name of your hypervisor, to avoid naming > > conflicts, e.g. > > > > /sys/hypervisor/tilera-hv/board/board_serial > > I don't see an easy way to put a directory in /sys/hypervisor. It seems > complex to create a kobject and a suitable class, etc., just for a > subdirectory. Or is there something simple I'm missing? I'll keep looking. > > I also suspect just "tile" is an adequate subdirectory name here in the > context of /sys/hypervisor, e.g. /sys/hypervisor/tile/version. I just checked for other users. The only one I could find was drivers/xen/sys-hypervisor.c, and it also doesn't use a subdirectory to identify that hypervisor. It's probably more consistent if you also don't do it then. You can create a directory with multiple files using sysfs_create_group() as the xen code does, but not nested directories. Arnd ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [PATCH] arch/tile: add /proc/tile, /proc/sys/tile, and a sysfs cpu attribute
(Resending with no HTML for LKML.) On 5/20/2011 3:59 PM, Arnd Bergmann wrote: > Any chance you can still restructure the information? I would recommend > making it a first-class procfs member, since the data is really per-task. > > You can add a conditional entry to tgid_base_stuff[] in fs/proc/base.c > to make it show up for each pid, and then just have the per-task information > in there to do the lookup the other way round: > > # cat /proc/484/hardwall > 2x2 1,1 @2,1 > > # cat /proc/479/hardwall > 2x2 1,1 @1,1 > Another problem with the existing interface is that it doesn't currently > support PID name spaces. That could of course be retrofitted, but having > the data split by pid directory would make it work implicitly. > > Another approach would be to have a /proc/hardwall/ directory with > one entry per hardwall instance, and symlinks from /proc//hardwall > to the respective file. I went ahead and implemented this, and will send out a v2 patch shortly. I added the "hardwall" entry to both the tgid_base (since everything is reflected there) but also to the tid_base_stuff[], since it can be different (in principle) for different threads. I played around with using a symlink, but the bottom line seems to be that if I make it a symlink (via a SYM() macro in the table) it always has to exist -- so what does it point to when there's no hardwall activated? I tried making it point to /dev/null, but that just seemed silly. In the end I made /proc/PID/hardwall a file, either empty, or else containing the hardwall id. The actual hardwalls are then in /proc/tile/hardwall/NN, where NN is the hardwall id. I wrote a very simple hardwall id allocate/free pair; the pid allocator seemed too tied to task_structs. We only need at most NR_CPUS hardwall ids, so it's pretty simple to just use a cpumask to hold the set of allocated hardwall IDs. The contents of the hardwall ID file are then just a cpulist of the cpus covered by the hardwall, rather than introducing a new convention (as quoted above, e.g. "2x2 1,1"). Individual tasks that are in the hardwall can be found by reading the "hardwall" files, and we can learn where they are bound in the hardwall by reading the "stat" file as is normal for learning process affinity. > When you do a /sys/hypervisor/ interface, put everything into a subdirectory > under /sys/hypervisor with the name of your hypervisor, to avoid naming > conflicts, e.g. > > /sys/hypervisor/tilera-hv/board/board_serial I don't see an easy way to put a directory in /sys/hypervisor. It seems complex to create a kobject and a suitable class, etc., just for a subdirectory. Or is there something simple I'm missing? I'll keep looking. I also suspect just "tile" is an adequate subdirectory name here in the context of /sys/hypervisor, e.g. /sys/hypervisor/tile/version. -- Chris Metcalf, Tilera Corp. http://www.tilera.com ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [PATCH] arch/tile: add /proc/tile, /proc/sys/tile, and a sysfs cpu attribute
(Resending after marking LKML in my Thunderbird address book for "no HTML".) On 5/20/2011 3:59 PM, Arnd Bergmann wrote: > Any chance you can still restructure the information? I would recommend > making it a first-class procfs member, since the data is really per-task. > > You can add a conditional entry to tgid_base_stuff[] in fs/proc/base.c > to make it show up for each pid, and then just have the per-task information > in there to do the lookup the other way round: > > # cat /proc/484/hardwall > 2x2 1,1 @2,1 > > # cat /proc/479/hardwall > 2x2 1,1 @1,1 > Another problem with the existing interface is that it doesn't currently > support PID name spaces. That could of course be retrofitted, but having > the data split by pid directory would make it work implicitly. > > Another approach would be to have a /proc/hardwall/ directory with > one entry per hardwall instance, and symlinks from /proc//hardwall > to the respective file. I went ahead and implemented this, and will send out a v2 patch shortly. I added the "hardwall" entry to both the tgid_base (since everything is reflected there) but also to the tid_base_stuff[], since it can be different (in principle) for different threads. I played around with using a symlink, but the bottom line seems to be that if I make it a symlink (via a SYM() macro in the table) it always has to exist -- so what does it point to when there's no hardwall activated? I tried making it point to /dev/null, but that just seemed silly. In the end I made /proc/PID/hardwall a file, either empty, or else containing the hardwall id. The actual hardwalls are then in /proc/tile/hardwall/NN, where NN is the hardwall id. I wrote a very simple hardwall id allocate/free pair; the pid allocator seemed too tied to task_structs. We only need at most NR_CPUS hardwall ids, so it's pretty simple to just use a cpumask to hold the set of allocated hardwall IDs. The contents of the hardwall ID file are then just a cpulist of the cpus covered by the hardwall, rather than introducing a new convention (as quoted above, e.g. "2x2 1,1"). Individual tasks that are in the hardwall can be found by reading the "hardwall" files, and we can learn where they are bound in the hardwall by reading the "stat" file as is normal for learning process affinity. > When you do a /sys/hypervisor/ interface, put everything into a subdirectory > under /sys/hypervisor with the name of your hypervisor, to avoid naming > conflicts, e.g. > > /sys/hypervisor/tilera-hv/board/board_serial I don't see an easy way to put a directory in /sys/hypervisor. It seems complex to create a kobject and a suitable class, etc., just for a subdirectory. Or is there something simple I'm missing? I'll keep looking. I also suspect just "tile" is an adequate subdirectory name here in the context of /sys/hypervisor, e.g. /sys/hypervisor/tile/version. -- Chris Metcalf, Tilera Corp. http://www.tilera.com ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [PATCH] arch/tile: add /proc/tile, /proc/sys/tile, and a sysfs cpu attribute
On 5/20/2011 3:59 PM, Arnd Bergmann wrote: > Any chance you can still restructure the information? I would recommend > making it a first-class procfs member, since the data is really per-task. > > You can add a conditional entry to tgid_base_stuff[] in fs/proc/base.c > to make it show up for each pid, and then just have the per-task information > in there to do the lookup the other way round: > > # cat /proc/484/hardwall > 2x2 1,1 @2,1 > > # cat /proc/479/hardwall > 2x2 1,1 @1,1 > Another problem with the existing interface is that it doesn't currently > support PID name spaces. That could of course be retrofitted, but having > the data split by pid directory would make it work implicitly. > > Another approach would be to have a /proc/hardwall/ directory with > one entry per hardwall instance, and symlinks from /proc//hardwall > to the respective file. I went ahead and implemented this, and will send out a v2 patch shortly. I added the "hardwall" entry to both the tgid_base (since everything is reflected there) but also to the tid_base_stuff[], since it can be different (in principle) for different threads. I played around with using a symlink, but the bottom line seems to be that if I make it a symlink (via a SYM() macro in the table) it always has to exist -- so what does it point to when there's no hardwall activated? I tried making it point to /dev/null, but that just seemed silly. In the end I made /proc/PID/hardwall a file, either empty, or else containing the hardwall id. The actual hardwalls are then in /proc/tile/hardwall/NN, where NN is the hardwall id. I wrote a very simple hardwall id allocate/free pair; the pid allocator seemed too tied to task_structs. We only need at most NR_CPUS hardwall ids, so it's pretty simple to just use a cpumask to hold the set of allocated hardwall IDs. The contents of the hardwall ID file are then just a cpulist of the cpus covered by the hardwall, rather than introducing a new convention (as quoted above, e.g. "2x2 1,1"). Individual tasks that are in the hardwall can be found by reading the "hardwall" files, and we can learn where they are bound in the hardwall by reading the "stat" file as is normal for learning process affinity. > When you do a /sys/hypervisor/ interface, put everything into a subdirectory > under /sys/hypervisor with the name of your hypervisor, to avoid naming > conflicts, e.g. > > /sys/hypervisor/tilera-hv/board/board_serial I don't see an easy way to put a directory in /sys/hypervisor. It seems complex to create a kobject and a suitable class, etc., just for a subdirectory. Or is there something simple I'm missing? I'll keep looking. I also suspect just "tile" is an adequate subdirectory name here in the context of /sys/hypervisor, e.g. /sys/hypervisor/tile/version. -- Chris Metcalf, Tilera Corp. http://www.tilera.com ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
