FIX: NixlConnector: do not skip short do_remote_prefill requests

[juncgu]

The original issue is #18490, and #18429 wanted to fix it.

But skipping short do_remote_prefill request in connector's metadata will also skip sending the notification to the prefill worker for releasing remote kv pages.

The modifications here are

1. revoke the changes from [Bugfix][Failing Test] Fix nixl connector test when promt size < block size #18429
2. update test_nixl_connector.py::test_prompt_less_than_block_size accordingly

FIX #18591

[github-actions]

👋 Hi! Thank you for contributing to the vLLM project.

💬 Join our developer Slack at https://slack.vllm.ai to discuss your PR in #pr-reviews, coordinate on features in #feat- channels, or join special interest groups in #sig- channels.

Just a reminder: PRs would not trigger full CI run by default. Instead, it would only run fastcheck CI which starts running only a small and essential subset of CI tests to quickly catch errors. You can run other CI tests on top of those by going to your fastcheck build on Buildkite UI (linked in the PR checks section) and unblock them. If you do not have permission to unblock, ping simon-mo or khluu to add you in our Buildkite org.

Once the PR is approved and ready to go, your PR reviewer(s) can run CI to test the changes comprehensively before merging.

To run CI, PR reviewers can either: Add ready label to the PR or enable auto-merge.

🚀

[wwl2755]

LGTM! Thanks for pointing out! Sorry for the oversight on existing logic of handling 0 block situation.

[njhill]

This overlaps with #18632 but it would be good to include your test changes.

[njhill]

@juncgu I've pulled your test updates into #18632 (still with you as the commit author).

[juncgu]

@juncgu I've pulled your test updates into #18632 (still with you as the commit author).

Thanks, @njhill. Then, I will close this PR.

[njhill]

@juncgu actually I reverted the test change because it was failing and I don't think it was correct.

When the number of tokens is < block_size, so that 0 blocks are to be sent, they are immediately freed and so the P worker doesn't require the D worker to make a request to free them. For this reason, the D worker side of the connector (correctly) does nothing the metadata contains no blocks.

[juncgu]

@juncgu actually I reverted the test change because it was failing and I don't think it was correct.

When the number of tokens is < block_size, so that 0 blocks are to be sent, they are immediately freed and so the P worker doesn't require the D worker to make a request to free them. For this reason, the D worker side of the connector (correctly) does nothing the metadata contains no blocks.

Yes, you are right, the current scheduler / connector_scheduler do not need the changes in the unit test.