Template:GSoC Project: Difference between revisions
From Xen
Jump to navigationJump to search
Lars.kurth (talk | contribs) (Formatting) |
Lars.kurth (talk | contribs) mNo edit summary |
||
Line 10: | Line 10: | ||
<tr><td style="background-color: #ECFCF4;">'''References''': {{{Refs|Not specified, useful references (mail threads / manuals / web pages) for students to learn background and motivation of the project. If the references are inlined in description, simply write "References inline in description".}}}</td></tr> |
<tr><td style="background-color: #ECFCF4;">'''References''': {{{Refs|Not specified, useful references (mail threads / manuals / web pages) for students to learn background and motivation of the project. If the references are inlined in description, simply write "References inline in description".}}}</td></tr> |
||
</table> |
</table> |
||
{{#if: {{{Review|}}} | <h6 style="font-size: 120%">Peer Review Comments</h6>{{{Review|}}} | }} |
{{#if: {{{Review|}}} | <hr><h6 style="font-size: 120%">Peer Review Comments</h6>{{{Review|}}} | }} |
||
}} |
}} |
Revision as of 10:06, 31 January 2013
[edit] [ ] Template documentation
Parameters
Notes on formatting
You can use any formatting withing the template (see Help:Formatting. Hiowever do note that you will need to be careful with line-breaks. Each line-break will result in a new parameter.
Required Project Fields
- Project : Project Title
- Date : Date of creation
- Contact : Mentor of project
- Difficulty : Level of difficulty for project
- Skills : Skills needed and other pre-conditions
- Desc : Description of project
- Outcomes: Project outcomes
- Steps: Necessary steps to accomplish project goal
- References: Useful references (mail threads / manuals / web pages) for students to learn background and motivation of the project. If the references are inlined in description, simply write "References inline in description".
Note that fields that have not been filled out are marked with a warning sign: . You may chose to explicitly suppress this warning by using the {{N/A}} template.
Meta Information
- Anchor : Anchor for project, e.g.
|Anchor=my-unique-anchor
can be referenced via[[#my-unique-anchor]]
- Review : This is a section which can be used for review comments and votes on the project. Please use the {{Comment}}, {{Vote}} and {{VoteNo}} templates to comment in this section
|Review {{Comments|~~~~:}} Comment 1 {{Comments|~~~~:}} Comment 2 {{Vote|~~~~}} Comment 3 {{VoteNo|~~~~}} Comment 4
Fields for Students
We will add additional fields for students, in due course.
Example
The following is an example of a GSoC project example using this template
{{GSoC Project |Project=Multiqueue support for Xen netback/netfront in Linux kernel |Date=01/22/2013 |Contact=Wei Liu |Difficulty=High |Skills=Linux kernel programming skill, knowledge of Xen PV device model. The candidate for this project should be familiar with open source development workflow as it may require collaboration with several parties. |Desc=Multiqueue support allows a single virtual network interface (vif) to scale to multiple vcpus. Each queue has it's own interrupt, and thus can be bind to a different vcpu. KVM VirtIO, VMware VMXNet3, tun/tap and various other drivers already support multiqueue in upstream Linux. Some general info about multiqueue: http://lists.linuxfoundation.org/pipermail/virtualization/2011-August/018247.html In the current implementation of Xen PV network, every vif is equipped with only one TX/RX ring pair and one event channel, which does not scale when a guest has multiple vcpus. If we need to utilize all vcpus to do network job then we need to configure multiple vifs and bind interrupts to vcpus manuals. This is not ideal and involves too much configuration. The multiqueue support in Xen vif should be straight forward. It requires changing the current vif protocol and the code used to initialize / connect / reconnect vifs. However, there are risks in terms of collaboration, it is possible multiple parties will work on same piece of code. Here are possible obstacles and thoughts: * netback worker model change - the possible change is from M:N to 1:1 is not really an obstacle because 1:1 is just a special case for M:N * netback page allocation mechanism change - not likely to have protocol change * netback zero-copy - not likely to have protocol change * receiver-side copy - touches both protocol and implementation, * multi-page ring - touches protocol and implementation, should be easy to merge * split event channel - touches protocol and implementation, should be easy to merge |Outcomes=The project is expected to have the following outcomes: * have multi-queue patch ready to upstream or upstreamed * benchmark report (basic: compare single-queue / multi-queue vif. advanced: compare Xen multi-queue vif against KVM multi-queue VirtIO etc.) }}
The above documentation is transcluded from Template:GSoC_Project/doc2. (edit | history) Editors can experiment in this template's sandbox (create) and testcases (edit) pages. Subpages of this template. A print version of this template exists at /Print. If you make a change to this template, please update the print version as well. |
Not specified, title of project
Date of insert: Not specified, date when created |
Mentor: Not specified, GSoC Mentor information |
Difficulty: Unknown |
Skills Needed: Unknown |
Description: Not specified, project description |
Outcomes: Not specified, project outcomes |
Steps: Not specified, necessary steps to accomplish project goal |
References: Not specified, useful references (mail threads / manuals / web pages) for students to learn background and motivation of the project. If the references are inlined in description, simply write "References inline in description". |
The above documentation is transcluded from Template:GSoC Project/doc. (edit | history) Editors can experiment in this template's sandbox (create) and testcases (edit) pages. Subpages of this template. A print version of this template exists at /Print. If you make a change to this template, please update the print version as well. |