GSoC 2007

[Sourav Pal]

Hello ,
I am applying for GSoC 2007 for the "Create an in-kernel API
for "packet classes""
project.

Please find the application at the following link :

http://crewman.uta.edu/~spal/netbsd_packet_class.html

Before I submit the application finally, any suggestions/advises is greatly
appreciated.

Regards,
Sourav

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Martin Husemann]

Post by Sourav Pal
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.

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

- 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.

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


Martin

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Sourav Pal]

Post by Martin Husemann

Post by Sourav Pal
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
- 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.

Post by Martin Husemann
- 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.

Post by Martin Husemann
- 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.

Post by Martin Husemann
- There should not be a new token field in mbufs, just use m_tag(9)

Yes. That's correct.

Post by Martin Husemann
Martin

Thanks for the reply.
Sourav

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Joerg Sonnenberger]

Post by Martin Husemann
- There should not be a new token field in mbufs, just use m_tag(9)

I would explicitly discourage m_tag. The overhead of maintaining another
two allocations per packet is IMO completely wrong. It was nice during
initial development of some subsystems, it is also useful for large
allocations like IPsec does, but in general firewalls and ALTQ should
get a few bytes in the packet header for this.

I tried that in DragonFly and it actually simplified e.g. PF quite a
bit.

Joerg

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[YAMAMOTO Takashi]

Post by Joerg Sonnenberger

Post by Martin Husemann
- There should not be a new token field in mbufs, just use m_tag(9)

I would explicitly discourage m_tag. The overhead of maintaining another
two allocations per packet is IMO completely wrong. It was nice during
initial development of some subsystems, it is also useful for large
allocations like IPsec does, but in general firewalls and ALTQ should
get a few bytes in the packet header for this.
I tried that in DragonFly and it actually simplified e.g. PF quite a
bit.
Joerg

how about tweaking m_tag api so that a few small tags can be allocated from
embedded storage in mbuf automatically?

YAMAMOTO Takashi

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Sourav Pal]

Post by YAMAMOTO Takashi

Post by Joerg Sonnenberger

Post by Martin Husemann
- There should not be a new token field in mbufs, just use m_tag(9)

I would explicitly discourage m_tag. The overhead of maintaining another
two allocations per packet is IMO completely wrong. It was nice during
initial development of some subsystems, it is also useful for large
allocations like IPsec does, but in general firewalls and ALTQ should
get a few bytes in the packet header for this.
I tried that in DragonFly and it actually simplified e.g. PF quite a
bit.
Joerg

how about tweaking m_tag api so that a few small tags can be allocated from
embedded storage in mbuf automatically?
YAMAMOTO Takashi

The m_tag API allows one to embed metadata information in the packets
(aka mbufs). As far as I know, it is already used by the VLAN
accelerator. I think the idea of of using a few definite types of
m_tags type of fixed size is simpler than allowing arbitrary metadata
sizes. Also, the information can be placed in the mbuf headers.
However, if a packet has been tagged with multiple tags, how do we
order the tags? Also, tags can be grouped into categories. Do we allow
ordering across groups or restrict ourselves within the groups only? I
think the best way is to overhaul the m_tag API (looks like YAMAMOTO
be in seconds with this). We can have APIs that order the tags,
inserts tags, deletes tags, .....This would also be a good time to do
away with the circular link list and move to a hash based approach..

Thanks,
Sourav

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Martin Husemann]

Post by YAMAMOTO Takashi
how about tweaking m_tag api so that a few small tags can be allocated from
embedded storage in mbuf automatically?

That is one option. Or some (maybe configurable number of) pointers to shared
(maybe ref counted) tags - this would fit things like ALTQ and the suggested
wlan output queues pretty well.

I discussed this with Pavel to length during last years "mbuf api enhancements"
SoC project. We explicitly considered Joergs (non-scalable) hack.

Pavel persuaded me that it is better to enhance mtag performance for all it's
uses, instead of just special casing one or two.

But I think this is orthogonal to this concrete project, and might be a good
research topic or another SoC project if there is SoC next year.


Martin

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de