Re: [Xen-devel] [PATCH RFC 1/2] xen: credit2: flexible configuration of runqueues

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

Hey Praveen,

Thanks for working on this and sending the patches!

A couple of things on the submission itself.

When we send more than 1 patch, we say that we send a "patch series".
That basically is a set of related patches. They may be related in
various ways. For instance, each patch may be a piece, or a step, for
implementing something (a feature, a bugfi, etc); or maybe they all do
something similar to either the same or different subsystems.

In any case, for making it better clear this fact that they are
related, these patch series always assume the following format:
- there is an email which acts as the introduction of the series, 
  which is often called cover letter, and is numbered as patch 0 of 
  the series;
- the emails containing actual patches, numbered starting from 1, are
  all sent as they were replies to the cover letter.

In the cover letter, one usually introduces an explains the work being
done, focusing on making it as easy as possible for the reviewers to
understand anything that it is important they know when looking at the
series.

There are several examples of patch series in the xen-devel mailing
list archives:
 https://lists.xen.org/archives/html/xen-devel/2017-02/threads.html

 https://lists.xen.org/archives/html/xen-devel/2017-02/msg03455.html
 https://lists.xen.org/archives/html/xen-devel/2017-02/msg01027.html
 https://lists.xen.org/archives/html/xen-devel/2017-01/msg02837.html

And the topic of sending patch series is covered here:
https://wiki.xen.org/wiki/Submitting_Xen_Project_Patches#Sending_the_patches_to_the_list

As per how to actually send the various emails in such a way  that they
get to the list in the proper format, there are tools.

I use stgit for development, and it supports doing that by means of
`stg mail'. A lot of people which use "just" git, do use
git-send-email.

On Fri, 2017-03-10 at 23:56 +0530, Praveen Kumar wrote:
> The idea is to give user more flexibility to configure runqueue
> further.
> For most workloads and in most systems, using per-core means have too
> many
> small runqueues. Using per-socket is almost always better, but it may
> result
> in too few big runqueues.
> 
> OPTION 1 :
> --------
> The user can create runqueue per-cpu using Xen boot parameter like
> below:
> 
>  credit2_runqueue=cpu
> 
> which would mean the following:
>  - pCPU 0 belong to runqueue 0
>  - pCPU 1 belong to runqueue 1
>  - pCPU 2 belong to runqueue 2
>  and so on.
> 
> OPTION 2 :
> --------
> Further user can be allowed to say something shown below :
> 
>  credit2_runqueue=0,1,4,5;2,3,6,7;8,9,12,13;10,11,14,15
> 
> or (with exactly the same meaning, but a perhaps more clear syntax):
> 
>  credit2_runqueue=[[0,1,4,5][2,3,6,7][8,9,12,13][10,11,14,15]]
> 
> which would mean the following:
>  - pCPUs 0, 1, 4 and 5 belong to runqueue 0
>  - pCPUs 2, 3, 6 and 7 belong to runqueue 1
>  - pCPUs 8, 9, 12 and 13 belong to runqueue 2
>  - pCPUs 10, 11, 14 and 15 belong to runqueue 3
> 
> ---
> PATCH 1/2 enables to create runqueue per-cpu [OPTION 1].
> ---
> 
So, this kind of high level summary about both patches 1 and 2 is
probably similar to what a cover letter for this series should contain.

Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel