WorldCIST'24 - 12nd World Conference on Information Systems and Technologies | Lodz, Poland

[WorldCIST-24]

* CORE Conference
** Google Scholar H5-Index = 25

*** Indexed in Scopus, WoS, DBLP, etc.




--  --  
--  -
WorldCIST'24 - The 12th World Conference on Information Systems and Technologies

Lodz University of Technology, Lodz, Poland, March 26-28, 2024

http://worldcist.org/ 


 -  --  
--  -



Scope

The WorldCist'24 - 12nd World Conference on Information Systems and 
Technologies,  to be held in Lodz, at Lodz University of Technology, Poland, 26 
- 28 March 2024, is a global forum for researchers and practitioners to present 
and discuss the most recent innovations, trends, results, experiences and 
concerns in the several perspectives of Information Systems and Technologies.

We are pleased to invite you to submit your original papers to WorldCist'24. 
All submissions will be reviewed on the basis of relevance, originality, 
importance and clarity.



Themes

Submitted papers should be related with one or more of the main themes proposed 
for the Conference:

A) Information and Knowledge Management (IKM);

B) Organizational Models and Information Systems (OMIS);

C) Software and Systems Modeling (SSM);

D) Software Systems, Architectures, Applications and Tools (SSAAT);

E) Multimedia Systems and Applications (MSA);

F) Computer Networks, Mobility and Pervasive Systems (CNMPS);

G) Intelligent and Decision Support Systems (IDSS);

H) Big Data Analytics and Applications (BDAA);

I) Human-Computer Interaction (HCI);

J) Ethics, Computers and Security (ECS)

K) Health Informatics (HIS);

L) Information Technologies in Education (ITE);

M) Technologies for Biomedical Applications (TBA)

N) Information Technologies in Radiocommunications (ITR);



Types of Submissions and Decisions

Four types of original papers can be submitted:

Full paper: Finished or consolidated R&D works, to be included in one of the 
Conference themes. These papers are assigned a 10-page limit.

Short paper: Ongoing works with relevant preliminary results, open to 
discussion. These papers are assigned a 7-page limit.

Poster paper: Initial work with relevant ideas, open to discussion. These 
papers are assigned to a 4-page limit.

Company paper: Companies' papers that show practical experience, R & D, tools, 
etc., focused on some topics of the conference. These papers are assigned to a 
4-page limit.

Submitted papers must comply with the format of Lecture Notes in Networks and 
Systems series (see Instructions for Authors at Springer Website) 
,
 be written in English, must not have been published before, not be under 
review for any other conference or publication and not include any information 
leading to the authors’ identification. Therefore, the authors’ names, 
affiliations and bibliographic references should not be included in the version 
for evaluation by the Program Committee. This information should only be 
included in the camera-ready version, saved in Word or Latex format and also in 
PDF format. These files must be accompanied by the Consent to Publish form 
filled out, in a ZIP file, and uploaded at the conference management system.


All papers will be subjected to a “double-blind review” by at least two members 
of the Program Committee.

Based on Program Committee evaluation, a paper can be rejected or accepted by 
the Conference Chairs. In the later case, it can be accepted as the type 
originally submitted or as another type. Thus, full papers can be accepted as 
short papers or poster papers only. Similarly, short papers can be accepted as 
poster papers only.

Poster papers and Company papers are not published in the Conference 
Proceedings, being only presented and discussed. The authors of accepted poster 
papers should build and print a poster to be exhibited during the Conference. 
This poster must follow an A1 or A2 vertical format. The Conference includes 
Work Sessions where these posters are presented and orally discussed, with a 7 
minute limit per poster.

The authors of accepted Full papers will have 15 minutes to present their work 
in a Conference Work Session; approximately 5 minutes of discussion will follow 
each presentation. The authors of accepted Short papers and Company papers will 
have 11 minutes to present their work in a Conference Work Session; 
approximately 4 minutes of discussion will follow each presentation.



Publication and Indexing

To ensure that a full paper or short paper is published and presented, poster 
paper or company paper is presented, at least one of the authors must be fully 
registered by the 5th of January 2024, and the paper must comply with th

Re: [PATCH 2/2] virtio-mmio: Support multiple interrupts per device

[Jakub Sitnicki via Virtualization]

Sorry for the delay in my response. I've been away at a conference.

On Tue, Oct 10, 2023 at 02:52 PM +08, Jason Wang wrote:
> On Sat, Sep 30, 2023 at 4:46 AM Jakub Sitnicki  wrote:
>>
>> Some virtual devices, such as the virtio network device, can use multiple
>> virtqueues (or multiple pairs of virtqueues in the case of a vNIC). In such
>> case, when there are multiple vCPUs present, it is possible to process
>> virtqueue events in parallel. Each vCPU can service a subset of all
>> virtqueues when notified that there is work to carry out.
>>
>> However, the current virtio-mmio transport implementation poses a
>> limitation. Only one vCPU can service notifications from any of the
>> virtqueues of a single virtio device. This is because a virtio-mmio device
>> driver supports registering just one interrupt per device. With such setup
>> we are not able to scale virtqueue event processing among vCPUs.
>>
>> Now, with more than one IRQ resource registered for a virtio-mmio platform
>> device, we can address this limitation.
>>
>> First, we request multiple IRQs when creating virtqueues for a device.
>>
>> Then, map each virtqueue to one of the IRQs assigned to the device. The
>> mapping is done in a device type specific manner. For instance, a network
>> device will want each RX/TX virtqueue pair mapped to a different IRQ
>> line. Other device types might require a different mapping scheme. We
>> currently provide a mapping for virtio-net device type.
>>
>> Finally, when handling an interrupt, we service only the virtqueues
>> associated with the IRQ line that triggered the event.
>>
>> Signed-off-by: Jakub Sitnicki 
>> ---
>>  drivers/virtio/virtio_mmio.c | 102 
>> +++
>>  1 file changed, 83 insertions(+), 19 deletions(-)
>>
>> diff --git a/drivers/virtio/virtio_mmio.c b/drivers/virtio/virtio_mmio.c
>> index 06a587b23542..180c51c27704 100644
>> --- a/drivers/virtio/virtio_mmio.c
>> +++ b/drivers/virtio/virtio_mmio.c

[...]

>> @@ -488,6 +511,18 @@ static struct virtqueue *vm_setup_vq(struct 
>> virtio_device *vdev, unsigned int in
>> return ERR_PTR(err);
>>  }
>>
>> +/* Map virtqueue to zero-based interrupt number */
>> +static unsigned int vq2irq(const struct virtqueue *vq)
>> +{
>> +   switch (vq->vdev->id.device) {
>> +   case VIRTIO_ID_NET:
>> +   /* interrupt shared by rx/tx virtqueue pair */
>> +   return vq->index / 2;
>> +   default:
>> +   return 0;
>> +   }
>
> Transport drivers should have no knowledge of a specific type of device.
>

Makes sense. This breaks layering. I will see how to pull this into the
device driver. Perhaps this can be communicated through set_vq_affinity
op.

>> +}
>> +
>>  static int vm_find_vqs(struct virtio_device *vdev, unsigned int nvqs,
>>struct virtqueue *vqs[],
>>vq_callback_t *callbacks[],

[...]

>> @@ -519,12 +544,51 @@ static int vm_find_vqs(struct virtio_device *vdev, 
>> unsigned int nvqs,
>> vqs[i] = vm_setup_vq(vdev, queue_idx++, callbacks[i], 
>> names[i],
>>  ctx ? ctx[i] : false);
>> if (IS_ERR(vqs[i])) {
>> -   vm_del_vqs(vdev);
>> -   return PTR_ERR(vqs[i]);
>> +   err = PTR_ERR(vqs[i]);
>> +   goto fail_vq;
>> }
>> }
>>
>> +   nirqs = platform_irq_count(vm_dev->pdev);
>> +   if (nirqs < 0) {
>> +   err = nirqs;
>> +   goto fail_vq;
>> +   }
>> +
>> +   for (i = 0; i < nirqs; i++) {
>> +   irq = platform_get_irq(vm_dev->pdev, i);
>> +   if (irq < 0)
>> +   goto fail_irq;
>> +   if (irq < irq_base)
>> +   irq_base = irq;
>> +
>> +   err = devm_request_irq(&vdev->dev, irq, vm_interrupt,
>> +  IRQF_SHARED, NULL, vm_dev);
>> +   if (err)
>> +   goto fail_irq;
>> +
>> +   if (of_property_read_bool(vm_dev->pdev->dev.of_node, 
>> "wakeup-source"))
>> +   enable_irq_wake(irq);
>
> Could we simply use the same policy as PCI (vp_find_vqs_msix())?

Reading that routine, the PCI policy is:

1) Best option: one for change interrupt, one per vq.
2) Second best: one for change, shared for all vqs.

Would be great to be able to go with option (1), but we have only a
limited number of legacy IRQs to spread among MMIO devices. 48 IRQs at
most in a 2 x IOAPIC setup.

Having one IRQ per VQ would mean less Rx/Tx queue pairs for a vNIC. Less
than 24 queue pairs. While, from our target workload PoV, ideally, we
would like to support at least 32 queue pairs.

Hence the idea to have one IRQ per Rx/Tx VQ pair. Not as ideal as (1),
but a lot better than (2).

Comparing this to PCI - virtio-net, with one interrupt per VQ, will map
each Rx/Tx VQ