On 3/26/07, Martin Husemann <martin@duskware.de> wrote:
> On Mon, Mar 26, 2007 at 10:25:33AM -0500, Sourav Pal wrote:
> > Before I submit the application finally, any suggestions/advises is greatly
> > appreciated.
>
> I haven't thought about the subject too much, so some of this may
> be lack of understanding on my side - but anyway, here are a few quick
> remarks:
>
>  - I don't think it is PCF's business to mark packets - this may just
>    be a misunderstanding or unclear language. The packet filter marks
>    packets with tags, but PCF is the one to dictacte the content of the
>    tag.

- PCF does not mark packets. PF marks packets based on matching
rulesets. PCF converts the matching tags to tokens that are understood
by the driver since the scope of tags are PF namespace limited.


>  - A nic or other driver will then be able to interpret some mbuf tags,
>    and use the "right" queue for the tag internally.

Yes, that what's I intended. The tokens are understood by the driver.
It can do whatever it wants to do based on the token markings.



>  - The tag-token matching does not need a grammar (AFAICT), but is only
>    a convention which names to use in the PF configuration so that a
>    nic driver can do the right things.
>
>  - I did not understand the whole /dev/pcf/<if_name> thing - I don't
>    think anything like that will be needed.

My original intension of /dev/pcf/<if_name> was to make the tokens generic.
Thus, a driver can define any tokens with priorities. We can avoid it by having
predefined tokens. For example, for IEEE 802.11 protocol there can be tokens
BE, BK, VI, VO. For NIC drivers there can be HPRIO, LPRIO.  The concern I have
is that we need to have a token pool generic enough for the drivers to use in a
meaningful manner. The word 'grammer' is a misnomer. It's actually a map.

>  - There should not be a new token field in mbufs, just use m_tag(9)
>

    Yes. That's correct.

> Martin
>

Thanks for the reply.
Sourav